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ABSTRACT 


Ships  are  plagued  by  eonneetivity  issues  while  underway  resulting  in  baeklogs  of 
data  needing  to  get  off  a  ship.  This  eapstone  projeefs  main  foeus  was  to  provide  the 
Commanding  Offieer  (CO)  the  eapability  to  seleet  and  prioritize  outgoing  data  flow  from 
ship-to-shore  dependent  on  their  ship's  operational  situation  while  afloat.  In  earrying  out 
this  effort,  the  team  focused  its  analysis  on  the  Navy's  Automated  Digital  Network 
System  (ADNS)  and  Information  Technology  (IT)  (i.e.,  shipboard  networks  and 
applications)  communities.  In  so  doing,  the  as-is  technical  status  and  current  state  of 
business  processes  were  captured  as  a  starting  point  for  the  work. 

The  team  learned  that  the  shipboard  IT  infrastructure,  ADNS  in  particular,  has  the 
technical  capability  to  prioritize  data  but  that  functionality  is  difficult  to  use  and  not 
widely  understood  by  shipboard  operators.  As  a  result,  most  prioritization  efforts  are 
done  ashore  (instead  of  on  the  ship)  which,  in  turn,  puts  extra  work  load  on  shore 
activities.  The  ADNS  community  is  striving  to  make  improvements  in  its  Quality  of 
Service  (QoS)  (prioritization  of  network  traffic)  and  this  effort  is  well  underway. 
Although  the  technical  infrastructure  seems  to  be  in  place,  the  functional  (user 
perspective)  aspect  of  ship-to-shore  data  prioritization  does  not  seem  to  be  well  organized 
and  formed.  This  is  probably  one  of  the  main  reasons  why  data  prioritization  seems  to  be 
performed  in  a  stove-pipe,  fragmented,  and  ad-hoc  manner,  and  conducted  ashore  instead 
of  on  the  ship. 

Thus,  a  framework  providing  a  ship-to-shore  data  prioritization  perspective  from 
a  systems  point  of  view  appears  to  be  missing.  This  framework  could  bring  the 
functional  and  technical  aspects  of  data  prioritization  together.  Accordingly,  the  team 
initiated  the  formulation  of  this  framework  in  several  ways.  First,  the  team  developed 
and  introduced  a  conceptual  prioritization  matrix  which  would  allow  the  CO  to  select  and 
prioritize  outgoing  data  based  on  the  ship"s  operational  situation.  Second,  the  translation 
of  war  fighter  situations  into  policies  which  would  feed  into  the  network  prioritization 
mechanism  was  explored.  Third,  a  data  and  domain  architecture  in  which  to  employ 
prioritization  was  developed.  Finally,  modeling  and  simulation  of  the  network 


V 


prioritization  mechanism  was  conducted.  It  is  recommended  that  the  work  that  had  been 
started  in  this  project  be  continued  and  further  developed  by  future  Naval  Postgraduate 
School  masters  and/or  doctoral  efforts. 
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EXECUTIVE  SUMMARY 


United  States  Navy  (USN)  ships  are  often  plagued  by  poor  eonnectivity  while 
underway.  Ship'h  connectivity  is  hampered  by  a  number  of  external  elements.  For 
example,  ships  operating  in  the  Arabian  Gulf  or  other  high  concentration  areas  have  to 
share  limited  satellite  resources.  As  a  result,  ships  are  given  small  satellite  connectivity 
windows  during  which  time  environmental  factors  such  as  heavy  seas  or  adverse  weather 
can  cause  periodic  loss  of  connectivity.  Furthermore,  a  ship"s  mission  may  sometimes 
necessitate  a  heading  resulting  in  the  mast  or  superstructure  interfering  with  the  direct 
line  of  sight  between  the  antenna  and  satellite  thus  negatively  impacting  connectivity 
while  this  situation  persists.  Losses  in  connectivity  on  a  regular  basis  result  in  a  backlog 
of  data  waiting  to  get  off  the  ship. 

This  capstone  project's  main  focus  was  to  provide  the  Commanding  Officer  (CO) 
the  capability  to  select  and  prioritize  outgoing  data  flow  from  ship-to-shore  dependent  on 
their  ship's  operational  situation  while  afloat.  In  so  doing,  a  more  smooth,  and  orderly 
flow  of  information  off  the  ship  would  be  realized  resulting  in  critical  data  getting  where 
it  is  supposed  to  go  in  a  timely  fashion.  The  project  team  used  a  customized  Classic 
Systems  Engineering  “Vee”  model  and  concentrated  on  the  left-hand  side  in  order  to 
analyze  the  problem  and  produce  a  conceptual  solution.  In  addition  to  researching 
available  technical  literature,  the  team  conducted  stakeholder  and  needs  analysis  by 
participating  in  technical  conferences  and  summits  and  interviewing  experts  in  the  field. 
The  team  focused  its  analysis  on  the  Navy's  Automated  Digital  Network  System  (ADNS) 
and  Information  Technology  (IT)  (i.e.,  shipboard  networks  and  applications) 
communities.  In  so  doing,  the  As-Is  technical  status  and  current  state  of  business 
processes  were  captured  as  a  starting  point  for  the  work. 

The  stakeholder  and  needs  analysis  resulted  in  a  list  of  capabilities  for  this  effort. 
These  capabilities  were  then  transformed  into  a  set  of  high  level  requirements.  The 
required  capabilities  were  divided  into  two  areas:  user  interface  and  prioritization 
mechanism.  The  user  interface  allows  the  user  (i.e.,  CO,  shipboard  operators,  etc.)  to 
enter  prioritization  information  into  the  system  based  on  the  ship's  operational  situation. 


The  prioritization  mechanism  translates  the  user-entered  prioritization  information  into 
algorithms  (or  policies)  that  carry  out  the  prioritization  tasking. 

The  team  learned  that  the  shipboard  IT  infrastructure,  ADNS  in  particular,  has  the 
technical  capability  to  prioritize  data  but  that  functionality  is  difficult  to  use  and  not 
widely  understood  by  shipboard  operators.  As  a  result,  most  prioritization  efforts  are 
done  ashore  (instead  of  on  the  ship)  which,  in  turn,  puts  extra  work  load  on  shore 
activities.  The  ADNS  community  is  striving  to  make  improvements  in  its  Quality  of 
Service  (QoS)  (prioritization  of  network  traffic)  and  this  effort  is  well  underway. 
Although  the  technical  infrastructure  seems  to  be  in  place,  the  functional  (user 
perspective)  aspect  of  ship-to-shore  data  prioritization  does  not  seem  to  be  well  organized 
and  formed.  In  other  words,  the  "how"  (solution)  seems  to  have  been  built  before  clearly 
defining  the  "what"  (whaf  s  needed  by  the  war  fighters).  This  is  probably  one  of  the  main 
reasons  why  data  prioritization  seems  to  be  performed  in  a  stove-pipe,  fragmented,  and 
ad-hoc  manner,  and  conducted  ashore  instead  of  on  the  ship. 

Thus,  a  framework  providing  a  ship-to-shore  data  prioritization  perspective  from 
a  systems  point  of  view  appears  to  be  missing.  This  framework  could  bring  the 
functional  and  technical  aspects  of  data  prioritization  together  so  that  technology 
developers  would  not  only  build  the  solution  right  but  also  build  the  right  solution  for  the 
war  fighter. 

The  team  initiated  the  formulation  of  this  framework  in  this  project  in  several 
ways.  First,  the  team  developed  and  introduced  a  conceptual  prioritization  matrix  which 
would  allow  the  CO  to  select  and  prioritize  outgoing  data  based  on  the  ship"s  operational 
situation.  Second,  the  translation  of  war  fighter  situations  into  policies  which  would  feed 
into  the  network  prioritization  mechanism  was  explored.  Third,  a  data  and  domain 
architecture  in  which  to  employ  prioritization  was  developed.  Finally,  modeling  and 
simulation  of  the  network  prioritization  mechanism  was  conducted. 

In  addition,  the  team  recommended  that  the  work  that  had  been  started  in  this 
project  be  continued  and  further  developed  by  future  Naval  Postgraduate  School  masters 
and/or  doctoral  efforts.  Future  work  could  involve  conducting  a  theater-wide 
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stakeholder's  funetional  requirements  Integrated  Produet  Team  (IPX).  This  group  would 
eontribute  elements  from  various  war  fighter  user  eommunities  and  elieit  high  level 
funetional  requirements  from  them.  A  user  interfaee  application  could  then  be  developed 
that  would  employ  the  prioritization  matrix  described  in  this  project.  This  would  give  the 
CO  the  capability  to  select  and  prioritize  data  based  on  the  ship"s  operational  situation, 
before  the  data  leave  the  ship.  An  automated  interface  service  for  the  network  could  be 
developed  to  receive  prioritization  information  from  external  application  sources.  An 
external  application  example  would  be  the  user  interface  described  earlier.  This  service 
would  translate  the  prioritization  information  from  external  application  sources  into  QoS 
policies  and  other  mechanisms  to  actually  implement  prioritization  within  the  shipboard 
networks.  Finally,  a  business  process  reengineering  project  could  be  performed.  This 
capstone  report  conceives  a  system  that  eliminates  the  status  quo  in  which  prioritization 
is  done  mainly  ashore  and  in  an  ad-hoc  manner.  In  other  words,  prioritization  would  be 
done  both  aboard  ship  and  ashore  but  would  have  to  be  consistent  between  them  so  as  to 
maintain  viable  communication.  Once  prioritization  can  be  fully  implemented  on  the 
ship  separately  from  shore,  continuing  to  perform  prioritization  ashore  could  cause  data 
conflicts  as  shore  facilities  get  out  of  synchronization  with  shipboard  activities. 
Therefore,  a  business  process  reengineering  would  be  needed  to  mitigate  this  risk. 
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I.  INTRODUCTION 


United  States  Navy  (USN)  Ships  are  often  plagued  by  poor  conneetivity  while 
underway.  Ship"s  connectivity  is  hampered  by  a  number  of  external  elements.  For 
example,  ships  operating  in  the  Arabian  Gulf  or  other  high  concentration  areas  have  to 
share  limited  satellite  resources.  As  a  result,  ships  are  given  small  satellite  connectivity 
windows  during  which  time  environmental  factors  such  as  heavy  seas  or  adverse  weather 
can  cause  periodic  loss  of  connectivity.  Furthermore,  a  ship"s  mission  may  sometimes 
necessitate  a  heading  resulting  in  the  mast  or  superstructure  interfering  with  the  direct 
line  of  sight  between  the  antenna  and  satellite  thus  negatively  impacting  connectivity 
while  this  situation  persists.  Losses  in  connectivity  on  a  regular  basis  result  in  a  backlog 
of  data  waiting  to  get  off  the  ship. 

This  capstone  project's  main  focus  was  to  provide  the  Commanding  Officer  (CO) 
the  capability  to  select  and  prioritize  outgoing  data  flow  from  ship-to-shore  dependent  on 
their  ship's  operational  situation  while  afloat.  In  so  doing,  a  more  smooth,  and  orderly 
flow  of  information  off  the  ship  would  be  realized  resulting  in  critical  data  getting  where 
it  is  supposed  to  be  in  a  timely  fashion.  A  high  level  outline  of  this  project  is  displayed  in 
Figure  1.  The  case  for  action  that  impelled  the  project  team  to  take  on  this  work  has  been 
defined  as  follows:  currently,  there  exists  no  means  by  which  COs  can  prioritize 
outgoing  data  flow  from  ship-to-shore  dependent  on  the  ship"s  operational  situation  while 
afloat.  As  a  result  of  this  case  for  action,  the  ship-to-shore  data  communication  project 
was  conceived  whose  vision  involves  the  development  of  a  system  that  gives  CO'h  the 
means  to  prioritize  outgoing  data  flow  dependent  on  ships”  operational  situations. 

The  main  actors  anticipated  to  be  actively  engaged  in  the  operation  of  this 
system"s  processes  include  both  COs,  defined  as  any  military  person  with  the  authority  to 
design  and  carry  out  prioritization,  and  shipboard  operators.  Other  key  actors  expected  to 
benefit  from  operation  of  this  system  include  the  Program  Executive  Office  for 
Command,  Control,  Communications,  Computers,  and  Intelligence  (PEO  C4I),  Space  and 
Naval  Warfare  Systems  Center  Pacific  (SPAWARSYSCENPAC),  and  the  Norfolk  Ship 
Support  Activity  (NSSA). 
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-Availability:  95 -98%  or  more. 

-  Reliability:  MTBF  >  2000  hours. 

-Usability:  Operator  Approval  80-90%  or  more. 
-Maintainability:  Downtime<  1  hr.per event. 
-Efficiency:  <  10%  packet  drop  on  average. 


Figure  1.  Process  Definition 


This  figure  provides  the  motivation  behind  the  development  of  the  ship-to-shore  data 
communication  system  along  with  the  system ’s  high  level  attributes. 


The  trigger  point  of  this  system  would  be  a  mission  change  in  the  ship"s  activities 
that  yields  the  need  for  changing  data  prioritization.  In  other  words,  the  CO  has  selected 
a  new  mission  for  their  ship,  battle  group,  task  force,  etc.  and  that  changing  mission  has 
resulted  in  changing  data  flow  priorities.  An  onboard  user  interface  then  allows  for  the 
changing  of  those  priorities.  First,  the  ship"s  operational  situation  is  selected  (e.g., 
underway  in  theater).  Next,  the  appropriate  activity  (mission)  is  chosen;  anti-submarine 
warfare  for  example.  Finally,  based  on  the  operational  situation,  activity,  and  other  CO 
inputs,  data  priorities  are  established  and  the  appropriate  prioritization  scheme  is 
implemented.  As  a  result,  the  changed  prioritization  scheme  now  represents  that  most 
conducive  way  in  meeting  the  ship''s  current  mission.  From  that  point  forward,  all  data 
flows  will  be  categorized  and  prioritized  based  on  this  new  prioritization  scheme. 
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Proposed  metrics  for  this  system  include  availability,  reliability  (measured  by  Mean  Time 
Between  Failure  (MTBF),  usability,  maintainability,  and  efficiency.  The  remainder  of 
this  paper  describes  the  system  in  greater  detail. 

A.  INITIAL  PROBLEM  STATEMENT 

Currently,  there  exists  no  means  by  which  a  CO  can  prioritize  outgoing  data  flow 
from  ship-to-shore  dependent  on  their  ship"s  operational  situation  while  afloat.  Each 
software  application  communicating  data  with  shore  must  come  up  with  its  own 
mechanism  for  transferring  that  data  over  the  same  satellite  connection.  As  a  result, 
when  the  ship''sdata  connection  is  limited  and/or  unreliable,  the  ship  creates  a  backlog  of 
data  requiring  transmission  to  shore.  This  backlog  congests  the  network  and  could  result 
in  the  following:  the  inability  to  transmit  necessary  data  that  could  affect  the  ship"s 
mission  (i.e.,  logistics  data  or  message  traffic);  inhibited  use  of  Secret  Internet  Protocol 
Router  Network  (SIPRNET)  chat  which  is  used  for  command  and  control  coordination 
between  other  ships;  and  shore  commands  and  delayed  e-mail  transmissions  which  could 
adversely  affect  ship'h  morale. 

Additionally,  the  various  data  transfer  mechanisms  contain  variations  and 
inconsistencies  between  their  respective  methodologies  and  traffic  load.  Eurthermore, 
little  to  no  coordination  takes  place  between  mechanisms.  These  facts  combined  with  the 
sheer  number  of  data  transfer  mechanisms  loading  the  ship''s  limited  communication 
bandwidth  pipeline,  leads  to  the  following  issues:  little  to  no  chance  for  optimization  or 
efficiency  improvement;  total  sustainment  costs  multiplying  with  each  additional 
mechanism,  competition  for  the  ship"s  communication  resources;  and  no  interoperability 
or  sharing. 

Communications  mechanisms  exist  on  board  ships  that  utilize  protocols,  such  as 
Simple  Mail  Transfer  Protocol  (SMTP),  that  are  used  by  multiple  applications  resulting 
in  a  reduced  reliability.  Applications,  like  the  Distance  Support/  Navy  Information 
Application  Product  Suite  (NIAPS)  file  transfer  procedures  (fiat  file)  result  in  unreliable 
and  inefficient  dissemination  of  data. 
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Although  infrastructure  such  as  Integrated  Shipboard  Network  System  (ISNS), 
Automated  Digital  Network  System  (ADNS),  and  Satellite  Communications  (SATCOM) 
is  currently  in  place,  they  allow  only  for  port  closure  to  regulate  the  number  of 
applications  that  can  transmit  off  the  ship.  They  currently  provide  no  means  for  CO  to 
set  application  priorities  that  would  allow  data  transmission  to  occur  in  an  efficient 
manner  and  ensures  that  the  most  prioritized  applications  have  the  earliest  opportunity  to 
reach  their  intended  destinations. 

B,  CAPSTONE  PROJECT  PARTICIPANTS 

The  Capstone  Project  Team  had  as  its  members,  ten  students  enrolled  in  the  Naval 
Postgraduate  School  (NPS)  Master  of  Science  in  Systems  Engineering  (MSSE)  and 
Master  of  Science  in  Engineering  Systems  (MSES)  program.  The  team  was  divided  into 
the  following  sub-groups  to  focus  on  individual  task. 


Table  1.  Capstone  Sub-groups 


header 

Edgar  C.  Pontejos 

Scheduler 

Phillip  Allen,  Michael  Brett  Huffman 

Eibrarian 

Capstone  Team 

Architecture 

Michael  Brett  Huffman,  James  W.  Pinner, 
Michael  J.  Roderick 

Modeling  &  Simulation 

Phillip  Allen,  David  P.  Gravseth,  Richard 

W.  Hughes,  Son  Nguyen 

Editors 

Capstone  Team 

Stakeholders  Analysis 

Bradley  J.  May,  Edgar  C.  Pontejos 

Prioritization  Matrix 

Bradley  J.  May,  Edgar  C.  Pontejos 

The  Capstone  Project  had  several  stakeholders  and  contributors.  Their  names  are 
listed  in  the  following  table. 
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Table  2.  Capstone  Project  Stakeholders  and  Contributors 


Name 

Organization 

Mary  Ellen  Nies 

PEO  C4I  (61610) 

Delores  Washburn 

PEO  C4I  (616A0) 

Alexander  Vasel 

SPAWARSYSCENPAC  (56550) 

Eric  K.  Otte 

SPAWARSYSCENPAC  (55130) 

Richard  E.  Coupland 

Naval  Undersea  Warfare  Center  (Code  25E) 

Michael  Morris 

NAVCYBERFOR  (N413) 

Kevin  Swann 

NSSA 

Floyd  Fahie 

NSSA 

Doug  Harding 

NSSA 

C.  SYSTEM  ENGINEERING  PROCESS 

This  project  used  a  customized  Classic  Systems  Engineering  “Vee”  delineated  in 
Figure  2.  Beginning  with  the  problem  statement,  the  team  researched  the  current 
customer  wants  and  musts.  In  this  context,  the  fleet  is  the  main  customer.  Then,  a  needs 
analysis  was  conducted  to  match  customer  concerns  with  the  problem  statement  which 
then  established  the  domain  (business  activity)  that  the  system  supports.  Encompassed 
within  this  domain  are  the  needs,  wants,  and  necessities  that  the  customer  perceived  as 
problems.  Following  are  the  requirements  elicited  through  stakeholder  interviews, 
derived  through  research,  and  system  analysis,  which  established  the  high-level  system 
requirements.  The  requirements  were  then  evaluated  and  further  developed  into  a  high- 
level  system  architecture  which  was  closely  tied  to  the  system"s  requirements. 
Subsequently,  a  component  conceptual  design  was  formulated.  Conceptual  system 
alternatives  to  address  the  problem  were  developed.  Modeling  and  simulation  were 
conducted  in  order  to  evaluate  system  performance,  conduct  trade-off  analysis,  and 
compare  the  alternatives.  Results  and  findings  were  then  packaged  as  the  recommended 
conceptual  solution  to  the  problem. 


5 


Figure  2.  Classic  Systems  Engineering  “Vee”  (Custom  Left-Side) 

This  is  based  on  the  standard  Systems  Engineering  “Vee”  model  utilized  in  the 
engineering  acquisition  process  in  accordance  with  DoD  5000-2R. 


D.  CAPSTONE  PROJECT  SCOPE 

The  following  defines  the  scope  of  this  project: 

•  USN  -  analysis  is  within  the  boundaries  of  the  USN; 

•  Limited  Set  of  Operational  Situations  -  only  a  selected  set  of  sample 
operational  situations  and  associated  activities  and  data  were  used; 

•  Navy  Ships  -  this  project  applies  to  afloat  (ships)  vessels  only  (i.e., 
submarines  are  out  of  scope); 

•  ADNS  Enabled  Navy  Vessels  -  this  project  does  not  apply  to  Navy 
vessels  that  use  ship-to-shore  communication  other  than  ADNS; 

•  Ship-to-shore  -  this  project  applies  to  ship-to-shore  (one  way) 
communication  only; 
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•  No  ship  to  ship  -  ship  to  ship  communication  is  out  of  scope; 

•  Outgoing  Data  -  this  project  applies  to  outgoing  data  only  (on  ship  data 
will  not  be  addressed); 

•  Within  Ship  Only  -  analysis  will  be  eonducted  within  the  ship  only  (e.g., 
SATCOM,  shore  Network  Operations  Centers  (NOC)  is  out  of  scope); 

•  ADNS  Enclave  -  this  projeet  applies  within  the  ADNS  enclave  only  (i.e., 
ISNS  is  out  of  scope);  and 

•  Non-secure  Internet  Protoeol  Router  Network  (NIPRNET)  -  this  projeet 
applies  to  NIPRNET  only. 

E,  ASSUMPTIONS 

Part  of  the  scope  of  this  project  is  limited  to  the  system  within  the  ship.  In  other 
words,  the  shore  elements  are  not  included  as  part  of  the  scope.  Therefore,  this  projeet 
assumed  that  there  is  some  type  of  meehanism  ashore  to  reeeive  and  proeess  the 
prioritized  data. 

In  simplifying  the  input  data  into  the  system,  this  projeet  assumed  that  the  data 
prioritization  decision  that  has  to  be  made  by  the  CO  could  be  reduced  by  the  following 
eriteria:  operational  situation,  activity  (or  mission)  type  of  data,  and  ranking  of  data.  The 
prioritization  matrix  is  based  on  this  assumption. 

It  is  assumed  that  once  the  process  is  underway  that  no  other  mechanism  will 
interfere  during  and  after  the  prioritization  of  the  data.  Otherwise,  any  form  of 
interferenee  could  disrupt  or  even  corrupt  the  prioritization  of  the  data. 

It  is  assumed  that  the  network  prioritization  infrastructure  (e.g.,  ADNS)  either  has 
or  could  have  the  eapability  (e.g.,  through  modifieation  if  necessary)  to  reeeive 
prioritization  information  from  external  application  sources. 
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F.  BACKGROUND  (BUSINESS  AND  INFORMATION  TECHNOLOGY 

DOMAIN) 

The  domain  of  this  project  is  comprised  of  two  areas:  business  and  Information 
Technology  (IT). 

The  business  domain  is  where  ship  personnel  carry  out  their  day-to-day  tasking 
and  processes.  For  example,  personnel  in  charge  of  supplies  perform  inventory 
management,  request,  issue,  processes  and  receive  materials.  Medical  personnel  may  see 
patients  and  carry  out  tasking  such  as  providing  immunizations.  The  CO  in  turn  may 
select  data  and  prioritize  them  (depending  on  the  operational  situation)  to  send  to  shore. 
All  these  happen  within  the  business  domain.  In  this  project,  the  term  “CO”  is  generic. 
The  “CO”  is  any  military  person  who  has  the  authority  to  decide  and  carry  out 
prioritization. 

The  IT  domain  is  the  technology  infrastructure  that  supports  the  business  domain. 
Technology  (hardware  and  software)  is  used  to  facilitate  and  automate  business 
processes.  For  example.  Integrated  Bar  Code  System  (IBS)  and  Naval  Tactical 
Command  Support  System  (NTCSS)  are  applications  that  are  used  in  supply  processes. 
The  Theater  Medical  Information  Program  (TMIP)  is  a  suite  of  medical  software  that  is 
used  in  medical  information  environment.  Software  is  hosted  in  hardware  computer 
systems  such  as  Personal  Digital  Assistants  (PDA),  workstations,  and/or  servers.  These 
computer  systems  are  interconnected  to  each  other  through  networks  so  that  they  can 
store,  exchange  data  with  each  other,  or  send  data  off  ship  to  the  shore.  All  these  happen 
within  the  IT  domain.  Figure  3  illustrates  this  IT  infrastructure  in  general  terms. 
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Figures.  IT  Infrastructure 

This  IT  domain  infrastructure  supports  the  ship 's  business  processes  that  occur  in  the 

business  domain. 

In  Figure  3  above,  Application  A  could  be  the  supply  software  IBS  and 
Application  C  could  be  NTCSS.  These  two  supply  applications  communicate  data  with 
each  other  but  the  data  may  stay  on  the  ship  only  (although  NTCSS  data  could  be  sent 
off-ship).  Application  B  could  represent  TMIP  and  Application  D  could  represent 
additional  software  that  sends  data  off  the  ship. 

The  following  sections  break  these  domains  down  in  more  details. 


1,  Business  Domain  (Operational  Situations  and  Activities) 

A  ship  may  be  in  one  of  several  possible  operational  situations.  For  example,  it 
may  be  underway  in  theater  or  it  may  be  underway  in  transit.  The  following  are 
examples  of  operational  situations:  underway  in  theater,  underway  in  transit,  homeport. 
United  States  (U.S.)  port  (other  than  homeport),  foreign  port,  and  dry  docked. 

Associated  with  each  operational  situation  are  activities  (or  missions).  For 
example,  while  in  the  underway  in  theater  operational  situation,  the  ship  may  be  engaged 
in  Air  Defense  (AD)  or  strike  activity.  The  following  are  examples  of  activities:  AD, 
Joint  Theater  Missile  Defense  (JTMD),  strike.  Naval  Surface  Fire  Support  (NSFS), 
Maritime  Intercept  Operations  (MIO),  Mine  Countermeasures  (MCM),  Antisubmarine 
Warfare  (ASW),  Surface  Warfare  (SUW),  Intelligence  Collection  (INTEL), 
Humanitarian  Operations,  and  Off  Station. 
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Ship  business  processes  such  as  supply  and  medical  generate  data  that  could  be 
tied  to  activities  (or  missions).  Other  day  to  day  business  activities  also  produce  data 
such  as  e-mail,  video,  and  voice  data.  The  following  are  examples  of  business  processes 
data:  video,  voice,  chat,  critical  e-mail  (i.e.,  that  sent  by  users  and/or  roles  deemed 
critical),  medical,  engineering.  Maintenance,  and  Material  Management  (3M)  data, 
administrative,  operations,  message  traffic,  training,  non-critical  e-mail,  web  browsing. 

Depending  on  the  ship"s  operational  situation,  some  of  the  business  process  data 
may  be  relevant  to  a  particular  activity  (or  mission).  In  addition,  some  of  the  data  may  be 
more  important  than  others.  Shore  commanders  may  have  a  need  for  such  data  to 
conduct  maritime  operational  planning,  for  example,  and  the  ship  CO  must  select  and 
prioritize  them  accordingly  before  they  leave  the  ship.  According  to  Kevin  Dugan's 
thesis,  "Navy  Mission  Planner"  [Naval  Postgraduate  School,  September  2007], 

"Maritime  operational  planners  continuously  address  the  complex  problems 
involved  with  the  employment  of  Navy  ships.  The  assignment  of  ships  to  missions  must 
take  into  account  ship  capabilities,  the  time  each  ship  is  available  in  theater,  distances 
and  transit  times  between  missions,  and  mission  values.  This  complicated  and 
multifaceted  staff  task  has  been  accomplished  up  to  this  point  largely  through  manual 
planning  efforts.  In  regards  to  the  number  of  maritime  missions  and  their  geographic 
dispersion  in  any  major  operation.  Navy  ships  continue  to  be  in  short  supply.  Surface 
and  subsurface  combatants  are  called  upon  to  cover  more  missions  and  more  geographic 
areas  than  is  possible  with  ships  that  are  available.  ” 

Therefore,  it  is  important  for  the  ship  CO  to  have  the  capability  to  select  and 
prioritize  data  before  the  data  leave  the  ship  in  order  to  provide  information  to  maritime 
operational  planners  and  to  support  other  naval  situational  awareness  and  decision 
support  needs. 

2.  IT  Domain  (The  Shipboard  Network  Architecture) 

The  USN  deploys  large,  enterprise-scale  Local  Area  Networks  (LANs)  aboard 
their  ships.  LANs  simply  represent  collections  of  computers,  printers,  and  other  devices 
connected  by  some  form  of  communication  channel  (wired  or  wireless).  This  setup 
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allows  users  to  communicate  and  share  resources  with  other  users.  USN  LANs  are 
organized  into  a  client-server  relationship.  Clients  are  merely  the  workstations  and  other 
peripheral  devices  that  the  sailors  use.  Servers  are  powerful  computers  running 
specialized  software  that  allows  them  to  “serve”  information  requests  from  the  clients. 
Examples  of  information  requests  include  sharing  files  or  other  data,  running  e-mail 
systems  or  websites,  and  hosting  applications  for  client  usage. 

Different  sections  of  the  network  such  as  clients  and  servers  that  are  connected  to 
one  another  are  often  referred  to  as  nodes.  Nodes  communicate  with  each  other  via 
switches.  Switches  are  hardware  components  that  control  information  flow  between 
nodes.  In  other  words,  switches  enable  data  transmission  from  one  node  (the  source 
node)  to  the  specific  node  for  which  the  data  was  intended  (the  destination  node)  while 
bypassing  all  the  other  nodes  on  the  network.  This  greatly  speeds  up  data  transmission  in 
a  network. 

Typical  USN  ships  contain  not  one  but  many  networks.  When  data  is  exchanged 
between  networks,  this  communication  is  facilitated  by  use  of  a  router.  The  router 
represents  another  piece  of  sophisticated  network  equipment,  like  the  switch.  Unlike  the 
switch,  however,  the  router  handles  information  flow  between  networks  as  opposed  to 
information  flow  between  nodes  on  the  same  network.  In  other  words,  any  time  data 
must  be  transmitted  between  two  networks,  routers  tell  the  data  where  to  go  and  how  to 
get  there. 

Lastly,  a  modem  (modulator/demodulator)  takes  the  digital  signals  being 
transmitted  over  the  LAN  and  converts  them  into  analog  signals  appropriate  for 
transmission  off  the  ship  through  a  satellite.  Extremely  High  Erequency  (EHE),  or  other 
communication  channel.  The  modem  either  interacts  with  the  router  or  is  integrated  into 
it.  USN  ships  use  a  specialized  piece  of  equipment  called  the  ADNS.  This  is  a  router 
integrated  with  a  modem  that  allows  shipboard  networks  to  communicate  off  the  ship.  It 
provides  Internet  Protocol  (IP)  connectivity  from  ship-to-ship  or  ship-to-shore  by 
efficiently  using  whatever  bandwidth  the  ship  has  available. 
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A  basic  shipboard  LAN  configuration  is  displayed  in  Figure  4.  Different  nodes 
on  the  network  such  as  workstations,  servers,  printers,  etc.  are  eonneeted  to  one  another 
via  switches.  This  simple  network  is  further  eonneeted  to  other  shipboard  networks  or  to 
off-ship  oommunieation  ehannels  via  a  router.  ADNS  represents  the  pathway  off  the 
ship. 

As  previously  mentioned,  USN  ships  eontain  many  different  networks.  The 
primary  ones  include  ISNS,  Submarine  Local  Area  Network  (SubLAN),  Combined 
Enterprise  Regional  Information  Exchange  System  Maritime  (CENTRIXS-M),  Global 
Command  and  Control  System  Maritime  (GCCS-M),  Sealable  Coherent  Interface  Eoeal 
Area  Network  (SCI  LAN),  NTCSS,  and  Video  Information  Exchange  System  and 
Shipboard  Video  Distribution  System  (VIXS/SVDS).  These  will  now  be  deseribed  in  a 
bit  more  detail. 


High  level  diagram  of  a  typical  shipboard  LAN.  [From  PMW 165,  2001] . 

ISNS  is  a  system  of  hardware  and  software  that,  taken  together,  forms  the  legacy 
network  infrastrueture  on  surfaee  ships  throughout  the  fleet.  Through  separate  hardware, 
it  ean  handle  all  elassifieation  levels  from  Top  Seeret  to  Unelassified.  SubLAN  is 
essentially  the  submarine  version  of  ISNS.  CENTRIXS-M  provides  secure  operational 
and  tactical  information  sharing  between  the  U.S.  and  eoalition  maritime  partners.  These 
partners  eonsist  of  seven  different  allied  groups  ineluding  Japan,  South  Korea,  the  North 
Atlantic  Treaty  Organization  (NATO),  and  the  Counter-Terrorism  Implementation  Task 
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Force  (CTITF).  GCCS-M  receives,  displays,  correlates  and  maintains  geographic 
location  data.  This  data  is  integrated  with  intelligence  and  other  environmental 
information  to  arrive  at  a  tactical  picture.  SCI  LAN  provides  a  separate  network  for 
transmission  and  receipt  of  special  intelligence.  It  operates  at  the  Top  Secret/  Sensitive 
Compartmented  Information  (TS/SCI)  level  of  clearance.  NTCSS  is  a  group  of  software 
applications  that  allows  the  ship''s  CO  and  crew  to  manage  maintenance  of  equipment, 
parts  inventory,  finances,  automated  technical  manuals,  personnel  data,  medical 
information,  etc.  VIXS/SVDS  supports  video  exchange,  streaming  video  distribution, 
and  Video  Teleconferences  (VTC). 

G.  THE  CURRENT  STATE  OF  ADNS  (AS-IS) 

ADNS  Increment  III  represents  the  newest  version  of  ADNS  and  is  currently 
deployed  on  nine  ships.  Plans  call  for  the  outfitting  of  the  fleet  (about  200  ships)  with 
ADNS  Increment  III  over  the  next  ten  years.  From  this  point  forward,  any  reference  to 
ADNS  means  ADNS  Increment  III  unless  otherwise  specified.  A  picture  of  an  ADNS 
terminal  is  shown  in  Figure  5. 


Figure  5.  Typical  Shipboard  ADNS  Terminal 
Picture  of  a  shipboard  rack  containing  the  ADNS  terminal  [From  USN,  2011]. 
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Figure  6  depicts  a  high-level  diagram  of  ADNS  and  the  systems  with  which  it 
interacts.  As  previously  noted,  ADNS  consists  of  a  router  integrated  with  a  modem  that 
allows  shipboard  networks  to  communicate  off  the  ship.  It  serves  as  the  information 
routing  center  distributing  data  between  shipboard  networks  and  the  available  Radio 
Frequency  (RF)  pathways  off  the  ship.  There  are  several  key  points  illustrated  in  Figure 
6,  first,  ADNS  handles  data  at  different  classification  levels.  Second,  in  addition  to  data, 
ADNS  also  bears  responsibility  for  voice  and  video  transmissions.  Last,  ADNS  manages 
available  bandwidth  to  ensure  that  data  travels  off  the  ship  on  the  most  appropriate  and 
efficient  path. 
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Figure  6.  ADNS  Fligh-Level  Diagram 

Depicts  how  ADNS  routes  data  from  various  shipboard  networks  to  shore  facilities 

[From  K.  Shah,  2011]. 


Since  all  data  traveling  off  the  ship  must  pass  through  ADNS,  it  acts  as  a  system 
bottleneck.  At  any  bottleneck.  Quality  of  Service  (QoS)  becomes  important.  QoS  is 
what  allows  the  network  to  make  smart  decisions  when  available  resources  cannot  keep 
up  with  network  traffic  loading.  Without  QoS,  all  network  traffic  going  off  the  ship  must 
compete  for  limited  bandwidth.  This  could  lead  to  mission-critical  data  getting  delayed 
or  dropped  and  not  reaching  its  destination  in  a  timely  fashion.  With  QoS,  higher  priority 
network  traffic  receives  a  greater  share  of  network  resources  than  lower  priority  traffic. 
This  ensures  that  network  traffic  is  delivered  as  expeditiously  and  efficiently  as  possible 
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while  also  maximizing  network  bandwidth  utilization.  ADNS  ensures  that  data,  voiee, 
and  video  are  routed  effieiently  by  managing  and  optimizing  the  use  of  RF  resourees.  It 
does  this  by  classifying  different  applications  and  routing  them  into  queues  based  on  that 
classification.  Each  queue  is  then  guaranteed  a  certain  bandwidth  based  on  the  marking 
of  data  packets  within  that  queue. 

Figure  7  displays  a  more  detailed  diagram  of  ADNS  and  other  interoperable 
systems.  The  blocks  labeled  Communities  of  Interest  (COI)  depict  areas  that  represent 
various  shipboard  networks  operating  at  different  security  classification  levels.  The 
figure  also  shows  data,  Voice  over  IP  (VoIP),  and  VTC  riding  across  these  networks  and 
applications  such  as  joint  communications  activity  and  Tactical  Data  Link  (TDL)  broken 
out  separately  in  the  Secret  domain.  However,  these  are  of  little  concern  to  the  remainder 
of  this  paper  and  will  not  be  discussed  further.  Each  COI  passes  data  through  a  router 
which  is  often  referred  to  as  an  edge  router  since  it  resides  at  the  outer  edge  of  its 
respective  network.  This  router  is  analogous  to  the  router  upstream  of  ADNS  shown  in 
Eigure  4. 
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Eigure  7.  ADNS  Detailed  Diagram 

Detailed  depiction  of  how  data  from  different  shipboard  networks  of  various 
classification  levels  travel  through  ADNS  to  the  ship 's  RF  infrastructure  [From  K.  Shah, 

2011]. 
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From  the  edge  router,  data  paekets  then  enter  a  paeket  shaper.  This  deviee  marks 
or  elassifies  the  paekets.  It  does  this  by  assigning  a  Differentiated  Serviees  Code  Point 
(DSCP)  marking  to  eaeh  data  packet.  Figure  8  shows  how  DSCP  marking  works.  Each 
packet  contains  a  type  of  service  field.  Six  bits  of  this  field  are  used  to  assign  a  DSCP 
marking  to  each  packet.  Thus,  26  or  64  different  markings  could  be  assigned  to  the 
packet.  This  marking  is  then  used  to  provide  QoS  in  the  network.  The  packet  shaper 
identifies  the  specific  application  that  generated  the  packet  and  then  marks  the  packet 
accordingly.  Table  3  lists  all  the  applications  currently  getting  assigned  QoS  markings  by 
ADNS. 
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Figure  8.  Differentiated  Service  Code  Point  (DSCP)  Marking 

Displays  how  the  type  of  service  field  within  a  data  packet ’s  header  can  be  used  to 
classify  that  packet  into  a  certain  data  category  [From  K.  Shah,  2011] . 
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From  the  packet  shaper,  marked  packets  then  pass  through  cryptographic 
equipment  (High  Assurance  Internet  Protocol  Encryptor  (HAIPE)).  Erom  there,  the 
encrypted  packets  go  into  ADNS  and  are  routed  to  specific  queues  based  on  their  DSCP 
markings  from  the  packet  shaper.  Table  4  lists  different  types  of  applications,  how 
ADNS  currently  marks  them  in  the  packet  shaper,  and  how  they  are  subsequently  routed 
into  a  queue. 


Table  4.  Application  Types,  Marking,  and  Queuing 


Realtime  ^ 
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Different  types  of  applications,  how  ADNS  currently  marks  them  in  the  packet  shaper 

fFrom  K.  Shah,  2011] 

The  ADNS  cipher  text  router  (cipher  text  because  it  is  on  the  encrypted  side  of  the 
HAIPE)  reads  the  DSCP  marking  of  each  packet  and  separates  them  into  queues 
accordingly.  Per  Table  4,  three  queue  types  exist:  first  In  first  Out  (flfO),  Eow 
Eatency  Queuing  (ELQ)  essentially  priority  queuing,  and  Class  Based  Weighted  fair 
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Queuing  (CBWFQ).  FIFO  and  LLQ  are  used  for  applications  providing  real-time 
services  (e.g.,  video  and  voice)  and  for  applications  providing  very  high  priority  traffic. 
Further  discussion  of  these  two  queue  types  in  the  remainder  of  this  paper  is  minimal. 
They  were  not  pertinent  to  the  problem  of  interest.  However,  the  CBWFQ  queue  type  is 
relevant. 

CBWFQ  provides  a  method  of  defining  different  classes  of  data  traffic  based  on 
some  criteria.  DSCP  markings  represent  the  criteria  ADNS  uses  to  define  traffic  classes 
in  shipboard  networks.  Different  applications  are  assigned  DSCP  markings  based  on  IP 
addresses,  ports,  and  protocols.  Packets  with  the  same  DSCP  markings  get  routed  to  the 
same  queue.  Each  queue  then  has  a  certain  amount  of  bandwidth  applied  to  it.  Queues 
containing  what  are  considered  to  be  higher  priority  packets  will  get  more  bandwidth 
assigned  than  those  queues  filled  with  what  are  considered  to  be  lower  priority  packets. 
If  a  queue  gets  too  full,  then  the  lower  priority  packets  get  dropped.  This  method  is 
referred  to  as  Weighted  Random  Early  Detection  (WRED)  and  it  creates  a  means  to  avoid 
network  congestion  while  ensuring  that  higher  priority  packets  pass  off  the  ship.  This 
process  is  diagrammed  pictorially  in  Figure  9. 


IP  packet 


WRED 


DSCP 

Differentiated  Services  Code  Points 


•Minimumthreshold 
•Maximu  m  th  reshold 
•Drop  probability 


Random 

drop 


Calculate  average 
queue  size 


Figure  9.  Weighted  Random  Early  Detection 
Basic  flowchart  showing  implementation  of  the  WRED  process  [From  K.  Shah,  2011]. 
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Per  Figure  9,  minimum  and  maximum  queue  size  thresholds  are  set  along  with  a 
paeket  drop  probability.  The  average  queue  size  is  ealeulated.  When  the  minimum 
threshold  is  exeeeded  in  a  queue,  lower  priority  paekets  are  randomly  dropped  based  on 
the  drop  probability  entered.  If  the  maximum  threshold  is  exeeeded  in  a  queue,  then 
paekets  at  the  tail  of  that  partieular  queue  begin  getting  dropped  as  well. 

In  addition  to  the  QoS  methodologies  previously  diseussed,  ADNS  uses  two  other 
means  to  improve  network  throughput.  These  are  eompression  and  aeeeleration. 
Compression  shrinks  the  size  of  eertain  paekets  to  improve  overall  network  eapaeity. 
However,  some  paekets  are  non-eompressible,  sueh  as  voice,  video.  Secure  Socket  Layer 
(SSL),  joint  communications  activity,  GCCS-M,  and  others.  Acceleration  helps  to  speed 
up  any  application  performance  that  has  been  slowed  by  latency  across  the  wide  area 
network  (WAN). 

Although  ADNS  represents  significant  improvements  over  prior  versions  of 
ADNS,  there  still  exist  other  improvement  features  that  could  be  added.  For  example, 
ADNS  can  allow  up  to  64  queues  to  be  used  based  on  DSCP  markings.  However,  not  all 
64  are  currently  used.  That  leads  to  the  possibility  of  generating  more  granularity  in  the 
way  applications  are  classified,  marked,  and  subsequently  prioritized.  Thus,  more 
applications  can  be  differentiated  from  one  another  in  terms  of  their  individual  priority 
relative  to  the  mission  at  hand.  This  leads  to  a  need  to  define  what  applications  are 
critical  based  on  the  particular  mission.  If  different  applications  have  different  priorities 
based  on  mission,  then  this  relates  back  to  the  need  mentioned  in  the  initial  problem 
statement  of  CO  having  the  ability  to  prioritize  outgoing  data  flow  from  ship-to-shore 
dependent  on  their  ship"s  operational  situation  while  afloat.  There  are  two  ways  to 
change  prioritization  given  the  current  construct  of  ADNS.  One,  when  application 
priorities  need  to  change,  change  the  markings  on  those  application"s  packets.  This 
would  then  change  the  queue  to  which  they  get  routed  such  that  higher  priority  packets 
go  to  queues  with  higher  bandwidth  allocation  and  vice-versa.  Two,  change  each  queue"s 
bandwidth  allocation  so  that  higher  bandwidth  gets  allocated  to  queues  containing 
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packets  with  higher  priorities  and  lower  bandwidth  gets  alloeated  to  queues  containing 
lower  priority  packets. 
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II.  PROBLEM  REFINEMENT  AND  NEED  ANALYSIS 


Community  areas  were  approaehed  for  stakeholder  representation  and  definitive 
requirements  for  the  validation  that  the  Capstone  project  was  on  a  path  to  provide  a 
useful  engagement  of  the  subject  to  add  value.  Stakeholder  identification  and  agreement 
was  of  the  utmost  importance  in  project  definition  to  make  sure  the  project  would  provide 
valuable  benefit  to  the  progress  being  made  in  areas  of  research.  Once  the  stakeholders 
were  identified,  a  focused  effort  was  utilized  to  identify  the  real  life  areas  of  requirements 
for  improvement  that  research  would  provide  the  most  benefit  back  to  the  end  user, 
stakeholders,  and  overall  community. 

A,  STAKEHOLDERS  AND  NEEDS  ANALYSIS 

Stakeholders  and  needs  analyses  were  accomplished  through  research,  reviewing 
literature,  interview  of  stakeholders  by  team  members,  and  through  participation  in 
conferences,  summits,  and  technical  working  groups. 

During  the  Fleet  Stakeholders  Conference  that  was  held  in  Norfolk,  Virginia,  in 
June  2011,  the  panel  of  flag  officers  delivered  several  messages  to  an  audience  comprised 
of  mainly  technology  providers.  They  gave  the  technology  providers  what  they 
perceived  as  the  fleet' 's  “wants  and  musts”.  They  challenged  the  technology  providers  to 
deliver  capabilities  faster,  at  reduce  costs,  and  avoid  proprietary  products  (i.e.,  use  open 
source).  In  addition,  they  asked  technology  providers  to  strive  for  the  following: 
compatibility,  interoperability,  reduced  interference  (including  protection  from  cyber 
attacks).  Common  Operating  Picture  (COP),  and  Commandefs  priority  (on/off  ship). 

Clearly  from  the  above,  providing  the  CO  with  the  capability  to  prioritize  is  a 
“very  real  subject  to  address”,  as  a  Science  and  Technology  (S&T)  assistant  program 
manager  Subject  Matter  Expert  (SME)  had  said  in  an  interview  during  the  stakeholders 
analysis. 

According  to  a  PEO  C41  ADNS  Acquisition  Program  Manager  (APM),  during  the 

stakeholders  analysis,  there  is  an  increasing  demand  from  some  fleet  operators  for  more 

granular  control  of  QoS,  i.e.,  prioritization  of  network  traffic.  However,  it  needs  to  be 
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balanced  with  the  reality  of  manning  levels  both  on  the  ship  and  at  the  shore  nodes  and 
their  workload.  Shore  sites  (i.e.,  Naval  Computer  and  Teleeommunieations  Area  Master 
Station  (NCTAMS)  /  NOCs)  have  a  very  demanding  job  just  keeping  all  eonneetivity  up 
with  the  ships  in  their  respeetive  theatres.  These  sites  should  not  have  to  respond  to 
individual,  ad-hoe  changes  in  QoS  for  eaeh  ship  beeause  that  would  be  unmanageable,  at 
least  with  the  technology  available  today. 

The  ship''s  ADNS  has  the  eapability  to  prioritize  outgoing  data  but  this  capability 
is  not  fully  utilized.  According  to  interviews  with  SMEs,  any  current  prioritization 
programming  is  not  generally  done  by  the  ship's  force.  It's  done  by  the  SMEs  at  the  In- 
Serviee  Engineering  Aetivity  (ISEA).  In  the  words  of  one  SME,  the  ship's  foree  has  the 
eapability  to  ehange  priorities  but  don't  really  know  they  have  that  eapability.  If 
prioritization  is  not  done  eorreetly,  it  ean  lead  to  an  unbalanee  network  that  ean  inerease 
eongestion  as  eertain  queues  constantly  fill  up.  That  can  lead  to  eritieal  messages  not 
getting  off  the  ship  or  the  network  going  down  eompletely.  One  reason  why  it's  so  hard 
for  the  ship's  foree  to  change  priorities  is  beeause  the  ADNS  teehnology  to  employ  the 
eapability  is  not  yet  fully  mature  and  is  laeking  eertain  key  elements  sueh  as  a  data 
marking  standard  that  all  related  technologies  eould  follow. 

One  of  the  partieipants  from  the  September  2011  QoS  Teohnieal  Summit 
eommented  that  this  effort  is  really  about  translating  war  fighter  situations  into  poliey  and 
expressed  the  need  to  have  a  framework  developed  for  articulating  war  fighter-driven 
poliey.  This  same  thought  was  shared  by  partieipants  in  the  September  2011  “Multi- 
Service  Limited  Teehnology  Experiment  (LTE)  Very  Important  (VIP)  Day.”  Another 
SME  suggested  changing  the  data  markings  and/or  ehanging  the  queuing  to  implement 
different  polieies  in  the  network.  That  is,  establish  a  statie  but  well  planned  queuing 
strueture  and  ehange  markings  as  needed  to  effeet  poliey  ehanges. 

B,  REFINED  PROBLEM  STATEMENT 

The  initial  problem  statement  of  this  effort  ehanged  slightly  as  the  team  learned 
more  information  through  its  researeh.  The  foeus  remained  the  same  whieh  was  to 


22 


provide  the  CO  the  eapability  to  select  and  prioritize  outgoing  data  flow  from  ship-to- 
shore  dependent  on  their  ship"s  operational  situation  while  afloat. 

The  team  learned  that  the  shipboard  IT  infrastructure,  ADNS  in  particular,  has  the 
technical  capability  to  prioritize  data  but  it  is  difficult  to  use  and  not  widely  known. 
Although  this  capability  is  not  widely  used  and  needs  improvement,  it  exists.  However, 
the  functional  (user  perspective)  aspect  of  ship-to-shore  data  prioritization  doesn't  seem 
to  be  well  organized  and  formed.  This  is  needed  in  order  to  drive  the  technical 
prioritization  capability  which  ADNS  provides.  In  other  words,  the  "how"  (solution) 
exists  but  the  "what"  (whaf s  needed)  seems  to  be  cloudy.  In  fact,  prioritization  seems  to 
be  performed  in  a  stove-pipe,  fragmented,  and  ad-hoc  manner.  As  a  result,  most 
prioritization  efforts  are  done  ashore  which  in  turn  puts  extra  work  load  on  shore 
activities.  What  seems  to  be  missing  is  a  framework  which  would  be  a  ship-to-shore  data 
prioritization  perspective  from  a  systems  point  of  view.  This  framework  should  bring  the 
functional  and  technical  aspects  together  and  help  bring  back  the  prioritization  effort  to 
the  ship  where  it  belongs  instead  of  having  it  done  ashore. 

The  team  focused  this  project  on  initiating  this  framework,  as  recommended  by 
some  of  the  stakeholders.  The  technical  aspect  of  data  prioritization  is  pretty  much  in 
place.  The  Navy's  ADNS  and  IT  community  is  well  underway  in  making  improvements 
and  trying  to  standardize  its  prioritization  capability,  along  with  making  network 
improvements  to  address  backlogs  and  traffic  congestions.  Rather  than  addressing  these 
subjects  directly  and  duplicating  ADNS'  effort,  the  team  paralleled  its  modeling  and 
simulation  work  with  what  the  ADNS  community  is  currently  exploring  and  focused  on 
the  prioritization  aspect,  that  is,  improvements  in  data  marking,  queuing,  and  QoS. 

The  team  focused  its  effort  in  establishing  the  conceptual  framework  for  the  ship- 
to-shore  data  prioritization  by: 

•  Developing  and  introducing  a  conceptual  prioritization  matrix  which 
would  allow  the  CO  to  select  and  prioritize  outgoing  data  based  on  the 
ship''s  operational  situation; 
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•  Exploring  the  translation  of  war  fighter  situations  into  poliey  whieh  would 
in  turn  feed  into  the  network  prioritization  mechanism; 

•  Developing  a  data  and  domain  architecture  in  which  to  employ 
prioritization;  and 

•  Modeling  and  simulating  the  network  prioritization  mechanism. 

C.  CONCEPT  OF  OPERATIONS 

The  CO  needs  the  ability  to  deliver  critical,  time-sensitive  information  from  their 
ship  to  other  ships  or  to  shore  whenever  required.  The  primary  mission  of  the  Ship-to- 
shore  Data  Communication  system  gives  the  CO  the  means  to  prioritize  outgoing  data 
flow  dependent  on  their  ship''s  operational  situation.  A  secondary  mission  yields  better 
congestion  management  of  unclassified  packets  so  as  to  minimize  network  congestion 
thus  facilitating  more  smooth  and  orderly  flow  of  critical  information  off  the  ship. 

A  high  level  flowchart  of  how  the  system  will  operate  is  displayed  in  Figure  10. 
This  system  concerns  itself  exclusively  with  unclassified  shipboard  networks  and 
applications.  Unclassified  packets  generated  at  the  start  of  the  flowchart  must  first  be 
categorized  in  accordance  with  some  categorization  criteria.  This  could  be  port  number, 
application  type,  source  address,  source-destination  pair,  or  some  other  criteria. 


Figure  10.  Ship-to-shore  Data  Communication  System  Flowchart 

Flowchart  describing  how  the  basic  Ship-to-shore  Data  Communication  system  process 

will  function. 
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Next,  each  categorized  packet  must  be  prioritized  according  to  some  prioritization 
scheme.  It  is  this  prioritization  scheme  that  the  system  will  provide  the  flexibility  for  CO 
to  change  based  on  their  ship"s  operational  situation.  Potential  operational  situations 
would  include  the  following:  underway  in  theater,  underway  in  transit,  homeport,  U.S. 
port  (other  than  homeport),  foreign  port,  and  dry  docked.  Only  the  underway  in  theater 
operational  situation  will  be  considered  for  this  Concept  of  Operations  (CONOPS).  It  is 
this  situation  for  which  a  variety  of  activities  (or  missions)  could  be  assigned  that  would 
cover  the  full  range  of  military  operations  of  interest.  The  other  operational  situations 
have  no  activities  of  interest  associated  with  them  and,  as  such,  are  left  for  further 
research  rather  than  being  considered  in  this  CONOPS.  Potential  assigned  missions  for 
the  underway  in  theater  operational  situation  are  listed  in  Table  5  along  with  a  brief 
description  of  each.  Prioritization  data  would  be  entered  into  the  system  via  a  user 
interface  in  accordance  with  entries  made  in  a  prioritization  template  much  like  that 
shown  in  Table  6.  In  Table  6,  the  activities  are  given  in  the  columns  while  the  rows 
contain  the  different  business  processes  requiring  prioritization.  Each  cell  in  the  template 
would  contain  some  kind  of  prioritization  number  relating  the  priority  of  each  business 
process  to  each  specific  activity.  For  the  purposes  of  this  CONOPS,  the  following  two 
assumptions  were  made  regarding  the  business  processes  listed  in  Table  6.  First,  video, 
voice,  chat,  and  critical  e-mail  will  always  possess  the  highest  priority.  Second,  non- 
critical  e-mail  and  web  browsing  will  always  be  assigned  the  lowest  priority.  Thus,  only 
the  middle  seven  business  processes  will  be  analyzed  further  in  this  research.  These 
seven  business  processes  include  medical,  engineering,  3M,  administrative,  operations, 
message  traffic,  and  training  which  are  the  regions  of  interest  for  the  reminder  of  the 
paper. 
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Table  5.  Mission  Types  and  Deseriptions 


Mission  Type 

Description 

Air  Defense  (AD) 

All  defensive  measures  designed  to  destroy 
attacking  enemy  aircraft  or  missiles. 

Joint  Theater  Missile  Defense  (JTMD) 

The  integration  of  joint  force  capabilities  to  destroy 
enemy  theater  missiles  in  flight  or  prior  to  launch  or 
to  otherwise  disrupt  the  enemy"s  theater  missile 
operations. 

Strike 

An  attack  which  is  intended  to  inflict  damage  on, 
seize,  or  destroy  an  objective. 

Naval  Surface  Fire  Support  (NSFS) 

Fire  provided  by  Navy  surface  gun  and  missile 
systems  in  support  of  a  unit  or  units  in  the  field. 

Maritime  Interception  Operations  (MIO) 

Efforts  to  monitor,  query,  and  board  merchant 
vessels  in  international  waters  to  enforce  sanctions 
against  other  nations. 

Mine  Countermeasures  (MCM) 

All  offensive  and  defensive  measures  for  countering 
a  naval  mine  threat. 

Anti-Submarine  Warfare  (ASW) 

Operations  conducted  with  the  intention  of  denying 
the  enemy  the  effective  use  of  submarines. 

Surface  Warfare  (SUW) 

Operations  conducted  to  destroy  or  neutralize 
enemy  naval  surface  forces  and  merchant  vessels. 

Intelligence  Collection  (Intel) 

The  acquisition  of  information  and  the  provision  of 
this  information  to  processing  elements. 

Humanitarian  Operations 

Disaster  relief,  goodwill  visits,  etc. 

Off-Station 

The  disposition  of  a  ship  when  it  is  in  a  region,  but 
it  is  unavailable  for  any  of  the  missions  previously 
defined. 
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Table  6.  Prioritization  Matrix  Example  Template  (Underway  in  Theater) 
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A  user  interface  is  needed  to  allow  the  CO  the  ability  to  enter  in  the  prioritization 
data.  A  high-level  Unified  Modeling  Language  (UML)  class  diagram  representing  this 
potential  user  interface  is  displayed  in  Figure  1 1 .  The  appropriate  operating  situation  and 
activity  (mission)  are  chosen  by  the  user.  This  leads  to  the  generation  of  a  lookup  code 
allowing  the  correct  prioritization  values  to  be  pulled  from  the  prioritization  matrix. 
These  prioritization  values  are  pulled  based  on  operating  situation  and  activity  and 
aligned  with  their  respective  business  processes  into  a  corresponding  priorities  array. 
This  array  of  prioritization  data  is  then  transferred  across  the  user  interface  boundary  to 
the  other  related  shipboard  systems.  In  this  way,  packets  can  be  prioritized  correctly 
based  on  the  ship''s  operational  situation  and  assigned  mission. 

The  entire  process  can  be  summarized  by  the  swim  lane  diagram  of  Figure  12. 
Three  major  roles  are  considered  essential  to  entering  in  the  appropriate  data  and  making 
the  prioritization  matrix  a  reality.  First,  the  CO,  as  previously  discussed,  refers  to  a 
generic  responsibility.  This  responsibility  includes  the  authority  to  set  the  mission  and 
establish  appropriate  priority  levels  for  packets  based  on  that  mission.  Examples  of  CO'h 
would  be  battle  group  commanders,  task  force  commanders,  or  the  captains  of  ships 
deployed  on  independent  operations.  Second,  the  platform  user  represented  by  any 
individual  onboard  a  ship  or  other  platform  that  has  the  responsibility  to  make  changes  to 
the  system  through  the  user  interface.  Third,  the  platform  authorizer  who  has  the 
authority  to  verify  that  any  changes  to  the  system  via  the  user  interface  were  made 
correctly  and  were  in  accordance  with  the  CD'h  directives. 

Once  packets  have  been  categorized  and  prioritized,  the  next  step  involves 
determining  whether  or  not  congestion  exists  in  the  network.  Thus,  some  kind  of 
congestion  detection  mechanism  must  exist  to  make  this  determination.  This  mechanism 
could  include  techniques  such  as  monitoring  queue  sizes,  measuring  output  line  usage  of 
key  network  devices,  monitoring  round-trip  delay  times,  using  a  source  probing  scheme 
to  determine  network  state,  or  setting  a  timeout  for  package  acknowledgement. 

When  no  congestion  exists  on  the  network,  packets  can  be  sent  off  the  ship 
without  engaging  any  sort  of  congestion  management  regime.  However,  they  still  will  be 
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sent  off  the  ship  based  on  the  prioritization  seheme  in  use.  This  will  be  based  on  some 
method  of  fair  queuing  that  would  ensure  all  paekets  receive  a  fair  share  of  the  available 
bandwidth  based  on  their  priority.  This  would  hopefully  minimize  the  amount  of 
congestion  realized  thus  keeping  the  necessity  of  implementing  congestion  management 
procedures  to  a  small  fraction  of  total  network  uptime.  In  the  instances  when  congestion 
does  exist,  then  certain  congestion  management  processes  will  be  initiated.  These  could 
include  such  things  as  source  throttling,  source  quench,  or  packet  dropping. 


Figure  1 1 .  Ship-to-shore  Data  Communication  System  Class  Diagram 


Shows  the  static  structure  of  notional  software  architecture  for  potential  use  in  the 

system ’s  user  interface. 
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Figure  12.  Swimlane  Diagram 

Defines  the  business  process,  key  roles,  and  key  responsibilities  associated  with  the  Ship- 

to-shore  Data  Communication  system. 
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Moving  forward  with  turning  this  concept  of  operations  into  a  physieal  reality, 
there  must  be  some  way  to  evaluate  potential  alternate  solutions.  Thus,  a  value  system 
must  be  generated  whose  primary  purpose  is  to  develop  a  value  hierarchy  that  can  be 
used  to  evaluate  various  alternatives.  The  value  system  for  this  projeet  is  shown  in 
Figure  13.  The  value  system  displays  what  funetions  and  sub-functions  the  system  must 
perform  to  be  suceessful  along  with  goals  and  requirements  against  which  success  can  be 
measured.  By  evaluating  each  potential  alternative  against  these  measures,  the  best 
overall  system  for  meeting  the  effective  need  can  be  determined.  A  more  detailed 
deseription  of  the  value  system  will  now  be  presented. 

D,  VALUE  SYSTEM 

The  value  system  consists  of  three  main  funetions:  classify  data  packets, 
prioritize  data  packets,  and  manage  network  congestion.  It  is  also  eomprised  of  six  key 
behaviors:  availability,  reliability,  usability,  maintainability,  interoperability,  and 

effieieney.  In  order  to  elassify  data  packets,  two  sub-funetions  must  be  performed.  First, 
eaeh  data  packet  type  must  be  successfully  identified.  This  eould  be  aecomplished  by 
determining  the  following  information  about  each  packet:  port  number,  application  type, 
source  address,  source-destination  pair,  or  some  other  eriteria.  Second,  based  on  the 
identifying  information  determined  for  eaeh  packet,  that  packet  is  marked  based  on  its 
type.  This  marking  will  then  be  used  by  the  prioritization  function. 

The  function  performing  data  packet  prioritization  consists  of  two  sub -functions: 
routing  to  a  queue  based  on  the  marking  and  assigning  a  priority  to  each  queue.  Based  on 
the  marking  applied  to  each  data  packet  based  on  its  type,  data  packets  are  assigned  to  a 
particular  queue  such  that  each  queue  contains  data  packets  of  similar  types.  Eaeh  queue 
is  then  assigned  some  prioritization  level  such  that  higher  priority  data  packets  reside  in 
the  higher  priority  queues  and  lower  priority  data  packets  reside  in  the  lower  priority 
queues.  Thus,  priority  level  of  data  packet  types  eould  be  changed  as  follows.  If  a 
certain  data  paeket  type  is  desired  to  have  a  higher  priority  level,  then  that  ean  be 
aeeomplished  by  either  changing  its  marking  such  that  it  goes  to  a  higher  priority  queue 
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or  changing  the  priority  assignment  of  the  queue  to  whieh  it  is  normally  sent  based  on  its 
marking. 

The  final  function  the  system  must  perform  involves  the  management  of  network 
congestion.  In  order  to  do  this,  the  presenee  of  network  congestion  must  first  be 
identified.  This  identification  could  be  made  using  such  techniques  as  monitoring  queue 
sizes,  measuring  output  line  usage  of  key  network  devices,  monitoring  round-trip  delay 
times,  using  a  source  probing  scheme  to  determine  network  state,  or  setting  a  timeout  for 
package  acknowledgement.  Then,  when  eongestion  does  exist,  it  must  be  alleviated. 
This  could  be  aceomplished  via  source  throttling,  source  quench,  or  packet  dropping  for 
example. 

In  addition  to  system  funetions,  several  system  behaviors  exist  upon  which 
alternatives  will  be  evaluated.  Availability  is  calculated  as  the  ratio  of  the  amount  of  time 
the  system  is  actually  operational  to  the  amount  of  time  it  is  expeeted  to  be  operational. 
Reliability  is  measured  by  the  average  or  mean  time  between  system  failures  requiring 
corrective  maintenance.  Usability  is  defined  as  the  ease  with  which  potential  operators 
ean  manipulate  the  system  with  a  reasonable  level  of  training.  This  behavior  will  be 
evaluated  based  on  user  satisfaction  surveys  that  will  allow  an  operator  approval  rating  to 
be  calculated.  Maintainability  is  measured  by  the  average  amount  of  time  the  system  is 
required  to  be  down  for  a  maintenance  event.  Interoperability  is  determined  by 
measuring  the  amount  of  commonality  in  terms  of  language  and  protocol  that  the  system 
has  relative  to  existing  systems  with  which  it  must  interoperate.  Efficiency  represents  the 
pereentage  of  paekets  required  to  be  dropped  as  a  result  of  congestion  management 
proeesses.  All  goals  for  these  behaviors  are  given  in  the  Value  System  diagram  of  Figure 
13. 

Thus,  alternatives  eould  be  evaluated  based  on  both  required  functions  and 
desired  behaviors.  This  would  mean  choosing  the  system  that  eomes  elosest  to  meeting 
all  the  behavioral  goals  plus  has  the  highest  probability  of  success  in  doing  the  following: 
identifying  data  packet  types,  assigning  markings  based  on  those  types,  routing  to  proper 
queue  based  on  marking,  assigning  correct  priority  to  each  queue,  identifying  network 

congestion  when  it  occurs,  and  alleviating  detected  congestion  when  required. 
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Figure  13.  Value  System 

Lays  out  the  key  functions  of  the  Ship-to-shore  Data  Communication  system  along  with  their  associated  sub-functions  and  pertinent 

metrics. 
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E,  OPERATIONAL  REQUIREMENTS 

Initially,  this  system  will  be  designed  for  roll-out  to  Guided-Missile  Destroys 
(DDGs)  and  Guided  Missile  Cruisers  (CGs).  It  is  expeeted  that  a  prototype  will  be 
installed  on  one  ship  of  eaeh  class  within  18-24  months.  Upon  successful  demonstration 
of  the  prototypes,  this  system  will  then  be  installed  on  two  ships  of  each  type  per  year 
until  fully  deployed  on  all  DDG  and  CG  platforms.  Consideration  of  system 
modification  for  roll-out  to  aircraft  carriers  and  amphibious  ships  (both  large  and  small 
decks)  will  be  made  at  later  dates.  Furthermore,  extension  of  this  system  to  include 
classified  shipboard  networks  will  also  be  evaluated  at  a  later  date.  It  is  anticipated  that, 
once  installed,  each  system  will  last  throughout  the  remaining  life  of  each  ship. 

This  system  will  operate  24  hours  per  day,  7  days  per  week.  It  will  run  as  long  as 
the  unclassified  shipboard  networks  and  their  associated  applications  are  running.  The 
only  time  this  system  will  not  be  operating  is  when  one  or  more  unclassified  networks  are 
down  for  routine  preventive  or  corrective  maintenance.  Availability  of  the  system  should 
be  greater  than  95%  with  a  stretch  goal  of  greater  than  98%.  MTBF  should  be  2000 
hours.  No  more  than  10%  of  packets  should  be  dropped  on  average.  The  usability  of  the 
system  should  be  such  that  normal  shipboard  operators  can  adjust  prioritization  schemes 
per  the  CO'h  direction  with  nominal  “on  the  job”  training.  Maintenance  on  the  system 
will  be  conducted  similarly  to  existing  shipboard  network  components  and  systems. 
Ship''s  force  will  handle  all  routine  preventive  and  corrective  maintenance.  More 
challenging  maintenance  items  will  be  shipped  off  to  intermediate  maintenance  facilities 
for  repair.  Major  repair  requirements  will  be  handled  at  depot  level  facilities  while  the 
ship  is  in  port. 

The  environment  in  which  this  system  is  expected  to  operate  will  be  the  expected 
environment  to  be  encountered  by  Navy  ships  underway  and  in  port  while  conducting 
normal  operations. 
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F.  PRIORITIZATION  MATRIX 

The  system  must  be  able  to  provide  the  CO  the  capability  to  prioritize  outgoing 
shipboard  application  data  based  on  the  ship"s  operational  situation.  As  mentioned 
previously,  the  ship  could  be  in  one  of  several  operational  situations  such  underway  in 
theater,  underway  in  transit,  homeport,  U.S.  port  (other  than  homeport),  foreign  port,  and 
dry  docked.  A  ship"s  operational  situation  could  involve  one  or  more  activities  such  as 
AD,  strike,  and  ASW.  See  Table  5  above  for  a  complete  list  of  activities.  This  research 
will  only  consider  the  underway  in  theater  operational  situation  as  that  contains  all  the 
activities  of  interest  to  this  paper.  For  each  activity,  there  exists  shipboard  business 
process  data  associated  with  it.  These  relationships  are  shown  above  in  Table  6. 

1.  Operational  Situation  and  Activity  Matrix 

The  matrix  in  Table  6  serves  as  a  basis  in  establishing  an  outgoing  shipboard 
application  data  prioritization  matrix  which  the  CO  will  input  as  control  for  the  system. 
With  this  matrix,  the  CO  could  identify  and  select  which  data  are  applicable  to  a 
particular  activity  within  an  operational  situation.  In  addition,  the  CO  could  assign 
ranking  as  to  which  data  get  the  highest  and  lowest  priority  when  leaving  the  ship.  This 
concept  is  shown  in  Figure  14  here;  the  Humanitarian  Operations  activity  is  used  as  an 
example. 
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Figure  14.  Operational  Situation  Mapped  to  Activity  Matrix 

A  storyboard  to  establish  an  outgoing  shipboard  application  data  prioritization  matrix 
which  the  CO  will  input  as  control  for  the  system. 

2,  Shipboard  Data  Prioritization  Matrix 

In  the  example  above,  the  Humanitarian  Operations  mission  portion  of  the 
prioritization  matrix  template  is  considered  in  isolation.  Priorities  are  assigned  to  each 
business  process  consistent  with  the  CO"s  perceived  needs  based  on  mission.  Here, 
video,  voice,  chat,  and  critical  e-mail  receive  highest  priority  while  non-critical  e-mail 
and  web  browsing  receive  lowest  priority  as  is  consistent  with  the  CONOPS  assumptions. 
Of  the  seven  remaining  business  processes,  medical  and  message  traffic  are  assumed  to 
be  of  greater  importance  for  this  mission.  Thus,  they  receive  higher  priority  than  the 
other  five  business  processes.  This  projecf's  recommendation  is  to  employ  the  above 
discussion  as  part  of  the  system  software.  A  potential  software  story  board  is  shown  in 
Figure  15. 
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Figure  15.  Prioritization  Matrix  Software  Story  Board 

A  storyboard  to  establish  an  outgoing  shipboard  application  data  prioritization  matrix 
which  the  CO  will  input  as  control  for  the  system. 


Internally,  the  software  would  map  the  outgoing  shipboard  applieation  data 
prioritization  matrix  to  a  list  of  IPs  and  ports  that  identify  the  data  within  the  network. 
For  example,  Medical  Info  would  have  a  unique  source  IP  address  (host)  and  port  number 
(application)  associated  with  it  which  will  allow  the  system  software  to  identify  it  and 
distinguish  it  from  the  other  shipboard  application  data  when  employing  the  prioritization 
algorithm. 

G.  HIGH  LEVEL  REQUIREMENTS  SUMMARY 

The  stakeholders  and  need  analysis  resulted  in  a  list  of  capabilities  for  this  effort. 
These  capabilities  were  then  transformed  into  a  set  of  high  level  requirements. 

The  required  capabilities  for  this  effort  are  divided  into  two  areas:  user  interface 
and  prioritization  mechanism.  The  user  interface  allows  the  user  (i.e.,  CO)  to  enter 
prioritization  information  into  the  system  based  on  the  ship's  operational  situation.  The 
prioritization  mechanism  translates  the  user  entered  prioritization  information  into 
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algorithms  (or  policies)  that  carry  out  the  prioritization  tasking.  User  interface  and 
prioritization  meehanism  requirements  are  contained  below  in  Table  7. 
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Table  7.  User  Interfaee  and  Prioritization  Meehanism  Requirements 


REQUIREMENTS 

STAKEHOLDERS 

DERIVED 

User  Interface  Requirements 

The  system  shall  provide  a  template  for  users  to  prioritize  data. 

X 

The  system  shall  provide  a  user  interface  to  define  prioritization  information. 

X 

The  user  interface  shall  be  able  to  list  the  different  operational  situations  for  its  host 
ship. 

X 

The  user  interface  shall  be  able  to  list  the  different  activities  (missions)  within  a 
particular  operational  situation. 

X 

The  user  interface  shall  be  able  to  list  the  different  data  that  are  applicable  to  an 
activity  within  a  particular  operational  situation. 

X 

The  user  shall  be  able  to  select  the  applicable  data  to  be  prioritized  for  a  particular 
activity  within  a  particular  operational  situation. 

X 

The  user  shall  be  able  to  define  prioritization  by  ranking  the  selected  data  for  a 
particular  activity  within  a  particular  operational  situation. 

X 

The  user  interface  shall  base  prioritization  information  using  the  user  defined 
ranking  of  the  selected  data. 

X 

The  user  interface  shall  transmit  the  prioritization  information  to  the  prioritization 
mechanism. 

X 

The  user  interface  shall  allow  the  user  to  change  prioritization  information  on- 
demand  (at  any  time). 

X 

The  user  interface  shall  be  able  to  accommodate  different  sets  of  operational 
situations/ activities/ data. 

X 

Prioritization  Mechanism  Reqnirements 

The  system  shall  translate  user  (war  fighter)  operational  situations  into  policy. 

X 

The  system  shall  provide  a  prioritization  mechanism  to  carry  out  the  prioritization 
tasking. 

X 

The  prioritization  mechanism  shall  receive  and  translate  prioritization  information 
from  the  user  interface. 

X 

The  prioritization  mechanism  shall  employ  data  marking  and  queuing  methodology. 

X 

Data  shall  be  marked  based  on  the  type  of  application  it  came  from. 

X 

Data  shall  be  marked  based  on  its  priority. 

X 

The  prioritization  mechanism  shall  send  high  priority  data  off  the  ship  first. 

X 

The  prioritization  mechanism  shall  loop  lower  priority  data  back  to  the  main  queue. 

X 

The  system  shall  implement  different  queuing  methods  to  avoid  congestion. 

X 

The  prioritization  mechanism  shall  apply  QoS  policies  in  order  to  manage  the 
prioritization. 

X 

The  prioritization  mechanism  shall  establish  a  set  of  QoS  policies  that  can  be  put  in 
place  based  on  the  prioritization  information  from  the  user  interface. 

X 

The  prioritization  mechanism  shall  employ  dynamic  (non-static)  QoS  policies  that 
adjust  with  changes  in  the  traffic  profile. 

X 

The  prioritization  mechanism  shall  be  able  change  prioritization  on-demand  in 
response  to  changes  in  user  input  via  prioritization  information  from  the  user 
interface. 

X 
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III.  ARCHITECTURE  AND  SIMULATION 


By  following  the  Systems  Engineering  “Vee”  model,  this  lead  to  the  next  steps  of 
identifying  arehiteeture  views  and  modeling  and  simulation  that  would  provide 
engineering  analysis  capturing  and  simulating  the  problem.  In  identifying  which 
architectures  to  utilize,  careful  consideration  was  taken  to  make  sure  that  the  views  would 
represent  the  problem  statement  and  identify  the  flow  throughout  the  system  process.  In 
the  next  sections,  the  views  that  were  thought  to  be  most  vital  in  telling  the  story  are 
discussed.  Then  the  modeling  data  and  analysis  provides  simulated  verification  and 
validation  to  the  alternatives  that  are  formulated. 

A.  ARCHITECTURE 

The  architecture  products  are  developed  from  the  viewpoint  of  the  ship. 
Additional  stakeholders  for  this  architecture  are  depicted  in  a  generic  context  since  the 
focus  of  the  capstone  deals  with  the  handling  of  information  on  the  ship.  Hence  as  will 
be  shown  throughout  the  discussions  in  this  section  the  use  of  generic  entities  versus 
specific  operational  entities  is  the  default. 

The  objective  was  to  describe  the  „As-Is''  architecture  as  the  basis  and  context  to 
describe  the  „To-Be"  architecture  which  represents  the  focus  of  the  capstone.  All 
architecture  products  developed  are  located  in  Appendix  A. 

1,  High-Level  Operational  Concept  Graphic  (OV-1) 

The  high-level  operational  concept  graphic  describes  a  capability  and  highlights 
main  operational  nodes  and  interesting  or  unique  aspects  of  operations.  It  provides  a 
description  of  the  interactions  between  the  subject  architecture,  naval  environment,  and 
between  the  architecture  and  external  systems. 

The  OV-1  describes  the  operational  focus  of  the  ship  on  supporting  ship-to-shore 
data  communications.  The  view  was  designed  to  represent  seven  data  areas  within  the 
ship  that  would  be  prioritized  before  being  transmitted  off  the  ship.  The  seven 
applications  are  medical  info,  operations,  3M  data,  administrative  data,  engineering  data. 
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message  traffie,  and  training  data.  The  view  illustrates  the  operational  environment  of  a 
ship,  mentioned  capabilities,  and  the  performers  exchanging  information  in  support  of  the 
missions.  The  arrows  and  lightning  bolts  depict  the  ships  communications  and 
connectivity  with  U.S.  NOCs  and  shore  facilities. 


Figure  16.  High-Level  Operational  Concept  Graphic  (OV-1) 

The  OV-1  high-level  operational  concept  graphic  describes  the  capability  and  highlights 
main  operational  nodes  and  interesting  or  unique  aspects  of  operations. 

2.  Operational  Node  Connectivity  (OV-2) 

The  OV-2  graphical  depiction  shown  below  in  Figure  17  provides  an  overview  of 
the  data  which  flows  from  a  typical  USN  afloat  vessel  underway  and  in  port.  The  OV-2 
highlights  the  typical  generic  data  nodes  by  subject.  It's  understood  that  these  generic 
nodes  would  actually  breakout  into  multiple  nodes  however,  to  reduce  the  time  required 
for  research  and  the  overall  complexity  of  the  OV-2,  the  decision  was  made  to  use 
generic  subject  nodes. 
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The  OV-2  is  focused  on  data  sources  that  have  the  ability  to  either  send  or  receive 
or  both  send  and  receive  the  specific  type  of  data  displayed  in  the  node  name.  This  OV-2 
demonstrates  the  sharing  of  high  level  Information  between  the  shore  data  source  and  the 
afloat  ship.  Specifically  the  information  depicted  is  (medical  info,  operations,  3M  data, 
administrative  data,  engineering  data,  message  traffic,  and  training  data)  as  these  are  the 
primary  areas  for  conducting  routine  business  when  a  ship  is  underway  or  in  port. 
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Figure  17.  Operational  Node  Connectivity  (OV-2) 

The  OV-2  depicts  the  nodes  and  need-lines  for  the  capstone  project. 
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B, 


MODELING  AND  SIMULATION 


Communication  of  data  off  a  USN  ship  underway  is  questionable  at  best. 
External  environmental  faetors  affeet  the  ability  of  a  ship  to  maintain  a  eonstant  data 
signal.  These  environmental  faetors  inelude  sea  state,  adverse  weather,  and  availability 
or  the  satellite  for  eommunieation.  Struetural  faetors  of  a  ship  also  affeet  the  ability  to 
maintain  a  eonstant  connection  such  as  when  the  ship''s  eourse  puts  the  mast  or 
superstructure  between  the  antenna  and  satellite.  The  unreliable  means  for  transmitting 
data  often  results  in  a  baeklog  of  data  needed  to  get  off  the  ship.  Modeling  and 
simulation  is  used  to  test  and  provide  analysis  to  different  aspects  of  this  problem. 

Two  models  were  utilized  to  show  different  perspeetives  of  the  problem.  The  first 
model  was  developed  using  ExtendSimV™,  to  determine  if  applying  data  marking  and 
priorities  would  result  in  a  higher  or  lower  throughput  of  prioritized  data.  The  seeond 
approaeh  used  the  Joint  Communieation  Simulation  System  (JCSS),  a  network  modeling 
tool.  The  JCSS  model  was  developed,  to  extended  the  eoneept  of  priority  queuing  and 
demonstrate  the  advantages  of  some  of  today"s  advaneed  QoS  teehniques.  The  JCSS 
baseline  seenario  showed  a  QoS  enabled  network.  Within  the  QoS  network,  it  ean  be 
shown  that  by  manipulating  differentiated  code  serviees  point  values  aeeording  to  the 
operational  eontext,  results  in  the  inerease  of  some  traffie  patterns.  Traffie  throughput 
ean  be  improved  for  the  eontextually  high  priority  applieations. 

1.  ExtendSimT™  Modeling  Approach 

The  first  model  was  developed  using  ExtendSimV™  to  determine  if  marking  and 

applying  a  prioritization  to  paekets  developed  by  different  applieations  and  put  through  a 

prioritized  queue  resulted  in  a  higher  transmission  rate  for  applieations  with  a  higher 

priority.  This  model  was  ereated  using  discrete  modeling  to  apply  properties  to  the 

paekets  as  they  were  developed.  As  paekets  were  developed,  to  simulate  the 

development  of  different  types  of  applieations,  the  paekets  were  filtered  through  different 

applieation  paths  using  probabilities  to  simulate  applieation  data  rates.  The  paekets  were 

then  given  a  priority  and  size  as  properties.  As  the  paekets  make  their  way  through  the 

prioritized  queue,  transmission  times  are  simulated  by  going  through  an  activity  that 
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holds  the  packet  based  on  the  packet  size.  After  packets  make  their  way  through  the 
transmission  activity,  the  packets  are  then  sorted  to  the  different  application  and  packet 
transmission  time  is  recorded.  The  process  described  here  is  representative  of  how 
packets  are  developed  by  different  applications  within  the  framework  of  a  ship''s  network 
infrastructure  and  pass  through  ADNS  for  transmission  off  the  ship. 


Figure  18.  Priority  Data  Marking  Model 

The  model  that  was  developed  using  ExtendSiml™  to  apply  prioritization  of packets  and 

to  compare  transmission  rates. 


2.  ExtendSimT™  Simulation  Parameter 


The  following  variables  exist  in  the  ExtendSimV^'^  model;  packet  generation  rate, 
packet  size,  packet  type,  and  the  priority  set  for  each  packet  type.  The  size,  type,  and  rate 
were  used  as  constants  in  the  model  to  compute  transmission  times  as  affected  by 
changes  in  priorities. 


3,  ExtendSimT™  Simulation  Results 

Appendix  B  contains  the  data  collected  from  the  ExtendSimT™  modeling  and 

simulation  effort.  The  ExtendSimT™  modeling  and  simulation  data  was  analyzed  to 

prove  the  statistical  validity  of  the  following  three  main  inferences:  1)  the  average 

transmission  time  for  each  data  category  is  approximately  equal  in  a  EIEO  methodology, 
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2)  the  average  transmission  time  for  a  data  category  will  decrease  based  on  the  priority 
level  assigned  to  a  data  category  and  3)  the  average  transmission  time  for  a  data  category 
having  the  same  priority  level  will  be  approximately  equal. 

The  data  of  Appendix  B  was  gathered  from  two  distinct  models;  a  base  model  and 
a  priority  model.  The  base  model  captures  the  average  transmission  time  for  every 
packet  when  each  data  category  is  assigned  equal  priority  (FIFO).  The  priority  model 
captures  average  transmission  time  for  each  data  category  as  it  is  assigned  a  distinct 
priority  level. 

As  the  population  sample  sizes  for  both  models  are  all  equal,  the  sample  sizes  of 
both  models  are  balanced  [Hayter,  2007].  The  base  model  has  seven  factor  levels 
corresponding  to  the  seven  populations  under  consideration.  The  priority  model  has  three 
distinct  factor  levels  corresponding  to  the  three  populations  under  consideration.  In  the 
base  model  equal  priority  levels  are  assigned  to  each  of  the  seven  data  categories.  Factor 
levels  in  the  priority  model  are  assigned  a  priority  level  of  one,  two,  or  three.  An 
Analysis  of  Variance  (ANOVA)  is  the  statistical  methodology  used  to  analyze  the 
resulting  data.  The  null  hypothesis  for  each  ANOVA  states  that  there  is  no  difference 
between  the  population  means  of  each  data  category. 

Figure  19  is  a  boxplot  of  the  average  transmission  times  of  each  data  category 
from  the  base  model.  The  data  of  Figure  19  suggest  that  the  average  transmission  time 
for  each  data  category  is  approximately  equal  when  a  FIFO  methodology  is  applied  to  the 
base  model.  The  statistical  significance  of  this  hypothesis  is  shown  to  be  extremely 
plausible  (see  Appendix  B)  as  the  p-value  of  the  ANOVA  is  much  greater  than  10% 
[Hayter,  2007].  The  Tukey  method  is  used  to  conduct  a  pairwise  comparison  between  the 
factor  levels  of  the  base  model,  and  it  is  determined  that  there  is  no  significant  difference 
between  factor  levels.  Thus,  it  is  safe  to  conclude  that  there  is  no  difference  between  the 
average  transmission  times  of  each  data  category  when  it  is  subjected  to  a  FIFO 
methodology. 


47 


Figure  19.  Boxplot  of  Base  model  average  transmission  times  for  each  data  category 
Average  transmission  times  for  each  data  category. 

Figure  20  and  Figure  21  illustrate  the  transmission  times  for  engineering  and 
training  data  when  they  are  assigned  priority  level  one,  administrate  and  message  traffic 
data  when  they  are  assigned  priority  level  two,  and  medical  and  3M  data  when  they  are 
assigned  priority  level  three.  The  data  suggests  that  the  average  transmission  time  and 
variance  increases  as  the  priority  level  increases.  The  ANOVAs  for  both  Figure  20  and 
Figure  21  prove  this  hypothesis  to  be  highly  plausible  as  the  p-values  are  much  less  than 
1%  [Hayter,  2007].  The  Tukey  method  is  used  to  conduct  a  pairwise  comparison 
between  the  factor  levels  of  priority  one,  two,  and  three.  The  Tukey  method  affirms  that 
data  categories  assigned  priority  level  three  are  significantly  different  than  the  data 
categories  assigned  priority  levels  two  and  one.  Data  categories  assigned  priority  levels 
two  and  one,  are  not  significantly  different.  Thus,  it  is  reasonable  to  conclude  that  the 
average  transmission  time  for  a  given  data  category  will  decrease  based  on  the  priority 
level  assigned  to  it  as  long  as  other  packets  exists  with  a  lower  priority.  This  is  a  direct 
relationship  and  relies  on  taking  bandwidth  from  lower  prioritization  data  to  provide  to 
higher  prioritized  data. 
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Saxplots  of  ENG,  ADMIN,  and  MED  data  set  to  priority  1,2,  and  3  respectively 


Figure  20.  Boxplot  of  transmission  time  for  prioritized  data 

Transmission  time  for  Engineering  (ENG),  Administrate  (ADMIN),  and  Medical  (MED) 
data  when  assigned  priorities  1,  2,  and  3  respectively 


Doxplots  of  TRNG,  MSG,  and  3M  data  set  to  priority  1,2,  and  3  respectively 


Figure  2 1 .  Boxplot  of  transmission  time  for  prioritized  data 

Transmission  time  for  Training  (TRNG),  Messaging  Traffic  (MSG),  and  3M  data  when 
assigned  priorities  one,  two,  and  three  respectively 

Figure  22  depicts  the  boxplots  of  each  data  category  as  it  is  assigned  priority  level 
one.  The  data  suggests  that  the  average  transmission  time  for  each  data  category  is 
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approximately  equal  when  each  data  category  is  assigned  the  same  priority  level.  The 
ANOVA  proves  this  hypothesis  to  be  highly  plausible  as  the  p-value  is  much  greater  than 
10%  [Hayter,  2007].  The  Tukey  method  is  also  used  to  conduct  a  pairwise  comparison 
between  the  transmission  times  for  each  factor  level.  The  Tukey  method  found  that  there 
was  no  significant  difference  between  engineering,  training,  or  operations  data  when 
assigned  the  priority  level  of  one.  Thus  it  is  safe  to  conclude  that  the  average 
transmission  time  for  data  categories  having  identical  priority  levels  is  approximately 
equal. 


Baxplots  of  ENG,  TRNG,  and  OPS  data  each  having  a  priority  of  1 


Figure  22.  Boxplot  of  highest  priority  transmission  times 

Transmission  times  when  each  data  category  is  assigned  priority  level  one 

4.  JCSS  Model 

The  JCSS  is  a  network  modeling  and  simulation  tool  developed  and  maintained 
by  the  Defense  Information  Systems  Agency  (DISA).  JCSS  is  based  on  the  Optimized 
Network  Engineering  Tool  (OPNET)  commercial  software  package.  JCSS  version  10.1 
was  used  for  this  effort. 

JCSS  was  developed  by  DISA  to  help  military  planners  consider  their  in-theater- 
communication  needs.  It  allows  the  communications  specialist  to  visualize  and  describe 
the  networks  used  for  various  military  units.  The  tool  is  specifically  designed  to  help 
identify  potential  bottlenecks  for  the  communications  infrastructure.  JCSS  helps  planners 
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understand  the  flow  of  time  critieal  messages  through  the  system  and  whether  the 
planned  infrastructure  is  sufficient  to  satisfy  the  demands  of  the  mission. 

JCSS  allows  the  user  to  construct  a  virtual  representation  of  the  network 
infrastructure  imposed  over  a  map  and  then  simulate  the  message  flow  through  this 
structure.  The  basic  framework  for  analysis  is  the  use  of  scenarios.  Typically,  a  user 
creates  a  baseline  scenario.  Then  this  baseline  is  modified  in  various  other  scenarios  that 
are  compared  to  the  baseline  and  each  other.  The  tool  provides  the  user  with  maps,  upon 
which  Operational  Facilities  (OPFACS)  are  placed  along  with  their  associated 
communications  equipment.  JCSS  provides  a  palette  of  hundreds  of  generic  and 
commercial  communication  devices  that  are  used  to  represent  the  network  infrastructure. 
Once  these  devices  are  placed  and  grouped  into  their  OPFACS,  they  are  configured  much 
like  their  real  world  counterparts  to  create  a  virtual  network.  Once  the  network  is  in 
place,  the  user  can  then  specify  Information  Exchange  Requirements  (lERs)  between 
OPEACS  and  identify  detailed  Measures  of  Performance  (MOPs)  to  determine  the 
efficacy  of  the  network. 

5.  JCSS  Model  Objective 

The  objective  of  the  simulation  was  to  compare  the  performance  of  ship-to-shore 
communications  using  a  “best  effort”  strategy  against  a  differentiated  services  QoS 
strategy.  A  “best  effort”  strategy  is  the  default  quality  of  service  strategy  afforded  by 
networks.  In  a  “best  effort”  approach,  all  IP  packets  are  treated  equally.  This  baseline  is 
representative  of  the  current  state  of  the  ADNS  network.  The  fundamental  problem  with 
treating  all  packets  equally  is  that  all  packets  are  not  truly  equal.  Certain  packets,  such  as 
routing  information,  are  more  important  because  they  are  essential  to  the  overall  health  of 
the  network.  Depending  upon  the  operational  context,  the  network  user  will  value  certain 
information  more  than  other  information.  Consider,  as  a  home  network  user,  a  scenario 
in  which  a  person  is  watching  a  movie  streamed  over  the  internet  or  playing  an  online 
game.  In  this  scenario,  the  person  would  typically  consider  the  packets  containing  the 
movie  stream  or  the  game  moves  more  important  than  email,  or  a  large  file  download  that 
is  happening  in  the  background.  With  a  best  service  approach,  all  the  traffic  is  treated 
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equally  and  therefore,  the  home  user  experienees  lots  of  delays  and  interruptions  in  their 
movie  watehing  or  gaming  experienee. 

Networks  are  typieally  eonfigured  to  provide  preferential  treatment  to  eertain 
elasses  of  network  traffie.  While  it  is  standard  praetiee  to  eonfigure  streaming  traffie  to 
take  preeedenee  over  non-streaming  traffie  for  obvious  reasons,  many  networks  do  not 
extend  the  use  of  QoS  teehniques  beyond  this  level.  While  it  is  helpful  to  use  a  home 
network  as  an  example  to  help  readers  understand  the  basie  eoneepts  behind  QoS 
polieies,  one  must  take  eare  not  to  extend  the  example  to  far.  One  big  and  obvious 
differenee  between  a  home  network  and  a  USN  ship  is  that  a  home  network  typieally 
only  has  one  type  of  priority  message  traffie  oeeurring  at  a  time.  That  is  to  say  that  a 
typieal  usage  seenario  sueh  as  watehing  a  movie  or  playing  an  online  game  most  often 
oeeurs  while  not  mueh  else  is  happening  on  the  network.  If  the  teenage  son  wishes  to 
game  online  while  his  parents  stream  a  movie  over  a  best  effort  network,  the  parents  are 
able  to  simply  shutdown  the  game  traffie  by  telling  the  son  that  he  will  have  to  wait  until 
they  are  done  watehing  the  movie.  Aboard  a  naval  vessel,  there  are  typieally  multiple 
priority  eommunieations  happening  all  at  onee.  A  multiple  priority  seenario  eannot  be 
handled  in  a  binary  fashion  that  ean  be  eonsidered  aeeeptable  in  a  home  network.  That  is 
to  say  that  in  a  multiple  priority  seenario,  it  is  undesirable  to  shutdown  all  other  traffie  to 
allow  one  partieular  flow  of  traffie  exelusive  aeeess  to  the  network. 

Instead  of  switehing  various  traffie  ehannels  on  and  off,  differentiated  serviee 
eodes  ean  be  used  to  aehieve  satisfaetory  performanee  aeross  the  broad  speetrum  of 
messages  that  must  be  eommunieated.  In  order  to  provide  satisfaetory  performanee, 
network  performanee  must  first  be  understood.  Network  performanee  ean  be 
eharaeterized  in  at  least  four  different  ways:  speed,  bandwidth,  throughput,  and  lateney. 

The  term  speed,  when  used  in  networking,  tends  to  be  related  to  rated  speed  of  a 
network  deviee  or  eonneetion.  This  term  is  generally  not  useful  as  a  MOP  sinee  it 
represents  a  theoretieal  limit  that  is  unaehievable  in  the  real  world.  While  it  is  true  that  a 
100BASE-T  line  ean  earry  data  faster  than  a  lOBASE-T  line,  this  faet  is  used  more  for 
the  planning  of  networks  than  as  a  measure  of  performanee. 
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While  the  term  bandwidth  refers  to  the  data-earrying  eapaeity  of  a  network  link,  it 
too,  is  largely  a  theoretieal  limit.  As  a  result,  it  is  more  useful  for  us  to  eonsider  the 
throughput  and  lateney  as  measures  of  performanee.  Throughput  measures  the  aetual 
amount  of  data  that  is  aetually  being  sent  aeross  a  network.  Speed  ratings  and  bandwidth 
of  network  eomponents  ultimately  limit  throughput.  Network  phenomena  such  as 
congestion  (high  percentage  of  packet  collisions)  degrade  throughput.  However,  in  an 
optimally  configured  network,  throughput  cannot  be  increased  beyond  the  theoretical  or 
practical  limits  of  the  physical  network.  Therefore,  in  a  saturated  network  condition, 
ceteris  paribus,  throughput  is  considered  bound  for  the  purpose  of  this  study. 

The  primary  MOP  is  latency  which  deals  with  the  timing  of  data  transfers  through 
a  network.  Latency,  like  many  other  performance  measures  is  multifaceted.  A  typical 
usage  of  the  term  latency  deals  with  the  elapsed  time  between  a  request  and  a  response. 
Streaming  media  applications  are  particularly  sensitive  to  this  type  of  latency.  An  on-line 
game  cannot  tolerate  this  type  of  latency  since  the  user  would  experience  a  noticeable  lag 
between  the  times  the  controller  button  is  pressed  to  the  time  the  resulting  action  appears 
in  the  game.  Similarly,  fire  control  systems  are  very  intolerant  of  this  type  of  high 
latency.  However,  other  systems  are  generally  more  elastic  in  their  ability  to  tolerate  this 
type  of  latency.  As  an  example,  email  systems  are  specifically  designed  to  support 
delayed  delivery.  A  user  composes  an  email  message.  The  message  is  then  queued  for 
delivery  until  a  network  connection  is  available.  The  acceptable  length  of  delay  from  the 
time  the  user  “sends”  the  email  to  the  time  it  is  ultimately  received  by  its  intended 
recipient  is  very  elastic.  Even  when  the  message  is  delivered  immediately  upon  being 
sent,  the  recipient  may  not  check  his  email  for  several  hours  or  days  after  the  message  is 
received  in  his  inbox.  Depending  on  the  nature  of  the  email  message,  this  delayed 
delivery  is  acceptable  up  to  some  amount  of  time  that  is  wholly  dependent  upon  the 
content  of  the  message  and  the  context  in  which  it  was  sent.  Certainly,  some  email 
messages  are  more  time  sensitive  than  others.  Even  still,  this  sensitivity  is  generally 
measured  in  hours  or  days,  instead  of  milliseconds. 

In  scenarios  that  involve  lossy  or  intermittent  connections,  a  backlog  of  messages 
can  build  up  during  periods  of  disconnectedness.  If  the  connection  is  in  and  out  such  that 
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prolonged  periods  of  conneetivity  are  a  rare  oeeurrenee,  the  network  never  aehieves  a 
stead  state  in  whieh  there  is  little  or  no  baeklog.  It  is  in  this  scenario  in  which  the 
prioritization  of  messages  becomes  critical.  Whenever  connectivity  is  reestablished  it  is 
important  that  the  most  critical  messages  be  delivered  first  since  it  is  unknown  how  long 
the  connection  will  last.  Applying  a  FIFO  approach  in  this  type  of  network  equates  to  a 
best  effort  approach.  This  means  that  letters  to  friends  could  be  delivered  before  mission 
related  data.  This  research  looked  at  ways  to  leverage  QoS  policies  to  ensure  that  the 
most  contextually  important  data  receives  priority  treatment  and  is  always  delivered  first. 
This  approach  cannot  eliminate  delays  due  to  loss  of  connectivity.  However,  it  will 
minimize  the  resultant  delay  for  the  most  important  data  in  the  context  of  the  current 
mission. 

Thus,  the  primary  MOP  for  this  study  is  message  delay.  The  purpose  of  the  JCSS 
model  is  to  show  that  differentiated  service  codes  can  be  used  to  minimize  message  delay 
relative  to  other  message  traffic.  QoS  technologies  typically  manipulate  messages  at  the 
packet  level.  This  fact  presents  a  limitation  to  the  degree  to  which  traffic  can  be 
prioritized.  If  email  is  considered  as  an  example,  all  email  looks  the  same  to  the  network. 
All  email  traffic  emanates  from  the  same  port  and  uses  the  same  protocols.  However,  an 
email  to  a  high  school  friend  certainly  has  a  lower  priority  aboard  a  ship  than  a  mission 
related  email.  To  achieve  this  finer  grain  of  prioritization,  there  are  63  differentiated 
service  code  point  values.  Obviously,  there  are  not  enough  code  values  to  provide  an 
arbitrary  level  of  prioritization.  However,  the  use  of  these  codes  can  provide  an 
incremental  improvement.  Obviously,  better  control  can  be  gained  at  the  application 
layer.  Initiatives  like  NIAPS  have  attempted  to  address  this  by  providing  a  single 
communication  bus  for  a  wide  variety  of  applications.  By  forcing  all  applications  to 
communicate  through  a  single  bus,  prioritization  at  the  application  level  can  be  achieved. 
This  prioritization  is  still  accomplished  using  queuing  technology  like  Multi-Server 
Multi-Queue  (MSMQ)  or  Java  Message  Service  (JMS).  Unlike  router  queues,  these 
queuing  technologies  are  backed  by  database  stores,  allowing  an  enormous  number  of 
messages  to  be  stored  in  a  semantically  complete  form  as  opposed  to  the  volatile  and 
potentially  network  router  queues.  This  application  layer  approach  deals  at  the 
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transactional  or  other  application-based  and  semantically  meaningful  package  level  as 
opposed  to  treating  individual  IP  packets  on  a  case  by  ease  basis. 

6.  JCSS  Model  Details 

The  network  model  used  in  this  project  is  based  upon  the  overall  network 
configuration  of  ADNS.  ADNS  is  the  WAN  interfaee  that  connects  ships  to  the  tactical 
network  over  a  satellite  link.  The  model  is  a  very  simplified  representation  of  the  JCSS 
network,  consisting  primarily  of  basic  routers  and  switches  with  application  servers  and 
simple  workstation  clients.  Advanced  technologies  like  HAIPE  are  not  included  in  the 
model  even  though  they  exist  in  the  ADNS  because  they  were  not  considered  germane  to 
the  study.  Similarly,  the  satellite  link  is  simulated  by  a  1.5Mbps  Point-to-Point  Protocol 
(PPP)  link  instead  of  using  a  real  satellite  model  object.  The  JCSS  model  is  depicted  in 
Figure  23. 
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JCSS  Model  depicting  ship-to-shore  communications. 


Several  servers  are  eonfigured  aboard  ship  and  connected  through  a  switch  that  is 
then  connected  to  the  shipboard  ADNS  router  (Figure  24).  This  subnet  is  notional  and  is 
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not  intended  to  represent  any  partieular  real  world  shipboard  network  sueh  as  ISNS.  The 
servers  merely  represent  message  traffie  endpoints.  All  QoS  is  eonfigured  on  the 
outbound  satellite  interfaee  on  the  shipboard  router.  This  study  foeused  on  ship-to-shore 
traffie  so  no  QoS  is  assigned  for  inbound  traffie.  Similarly,  this  study  is  not  concerned 
with  traffic  between  hosts  aboard  ship. 


Undasstfied  15  20 


JCSS  model  of  servers  that  are  configured  aboard  a  ship  and  connected  through  a  switch 
that  is  then  connected  to  the  shipboard  ADNS  router. 


Figure  25  shows  a  top  level  view  of  the  lER  demands.  These  demands  connect 
various  ashore  OPFACS  to  shipboard  servers.  Simple  workstations  serve  as  traffic 
generation  sites  in  each  of  these  OPFACS  ashore. 
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Figure  25.  Top  Level  View  of  lER  Demands 

Shows  a  top  level  view  of  the  lER  demands  which  connect  various  ashore  OFF  ACS  to 

shipboard  servers 


Figure  26  shows  a  typical  ashore  OPFAC  configuration.  The  messages  that  are 
passed  between  nodes  are  generated  automatically  from  the  information  exchange 
requirements  in  the  OV-2. 
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Figure  26.  OPFAC  configuration 
Shows  a  typical  ashore  OPFAC  configuration. 
57 


Figure  27  depicts  an  OV-2  as  configured  in  the  JCSS  model.  These  lERS 
represent  only  a  small  subset  of  the  lERs  depicted  in  the  model  for  the  sake  of  simplicity. 
The  lERS  are  listed  in  Table  8.  All  traffic  generated  in  the  model  represents  one  or  more 
instances  of  lERs. 


Figure  27.  JCSS  generated  OV-2 
Depicts  an  OV-2  as  configured  in  the  JCSS  model. 
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Table  8.  JCSS  Model  Information  Exchange  Requirements 


Consumers 

Name(s) 

Type  Equipment 

Protocoi 

Ciassification 

Priority 

ADNS.Ship.MessageSvr 

Message  Traffic 

DATA  Computer 

TCP 

Unciassified 

ROUTiNE 

3M_App_Data_Source.OE 

3MSvr->0E 

DATA  Computer 

TCP 

Unciassified 

ROUTiNE 

3M_App_Data_Source.OE 

Maintenance  Support  Request 

DATA  Computer 

TCP 

Unciassified 

ROUTiNE 

ADNS.Ship.OpsSvr 

Operationai  information 

DATA  Computer 

TCP 

Unciassified 

ROUTiNE 

Operations_Application_Data_Source.OE 

Operationai  Support  Requirements 

DATA  Computer 

TCP 

Unciassified 

ROUTiNE 

Operations_Application_Data_Source.OE 

Situationai  information 

DATA  Computer 
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Custom  configured  application  objects  were  used  to  generate  traffic  in  a  baseline 
scenario  and  a  humanitarian  mission  scenario.  The  simulation  was  configured  for  seven 
custom  applications  (administrative,  medical,  3M,  engineering,  training,  operations,  and 
message  traffic)  in  JCSS  with  various  JCSS  tasks  that  represent  lERs.  JCSS  provides  the 
task  object  to  allow  simulation  of  patterns  of  traffic  exhibited  by  an  application.  All 
custom  applications  were  configured  identically  and  were  assigned  one  or  more  tasks, 
each  of  which  is  configured  identically.  The  basic  task  includes  a  1KB  request  from  an 
application  client  and  a  100MB  response  from  the  respective  server.  Differences  in 
completion  time  will  be  directly  related  to  network  delays.  During  the  humanitarian 
mission  scenario,  medical  data  is  expected  to  have  higher  priority. 


7,  JCSS  Baseline  Scenario 

The  baseline  scenario  represents  a  condition  in  which  no  IP  QoS  is  configured. 
This  configuration  does  not  provide  differentiated  quality  of  service  based  on  any  type  of 
service  class.  Consequently,  all  packets  are  treated  equally  in  a  best  effort  configuration. 
Best  effort  is  JCSS''s  default  router  configuration  for  all  router  model  interfaces. 
However,  this  scenario  uses  a  FIFO  queue.  With  the  FIFO  queue  profile  applied,  the 
router  interface  queues  and  process  packets  in  the  same  order  as  they  would  in  the  default 
configuration.  The  FIFO  profile  is  applied  because  it  allows  us  to  limit  the  number  of 

packets  that  can  be  queued.  The  FIFO  profile  also  facilitates  the  gathering  of  network 
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interface  statistics.  Both  of  these  features  facilitate  comparisons  between  this  scenario 
and  other  scenarios  in  which  IP  QoS  is  configured. 

8,  JCSS  Baseline  Results 

As  expected,  the  equally  configured  applications  exhibit  a  near  uniform 
distribution  of  response  times.  The  application  response  time  represents  the  time  it  takes 
for  a  series  of  request  and  response  messages  between  a  client  and  server  participating  in 
a  defined  series  of  transactions. 


Table  9.  Application  Response  Time  in  seconds  (per  16  MB  transactions) 


Statistic 

Average 

Maximum 

Minimum 

3M  (seconds) 

4,025.90 

4,128.40 

3,936.35 

Admin  (seconds) 

4,006.12 

4,100.86 

3,952.36 

Medical  (seconds) 

4,003.92 

4,040.63 

3,960.54 

Messaging  (seconds) 

5,962.32 

6,008.14 

5,916.51 

Operations  (seconds) 

5,941.94 

6,048.00 

5,792.28 

Training  (seconds) 

4,000.32 

4,113.71 

3,916.56 

9,  Humanitarian  Mission  Scenario 

The  humanitarian  mission  scenario  is  configured  identically  to  the  baseline 
scenario  with  two  exceptions.  First,  a  class  CBWFQ  QoS  policy  with  WRED  for 
congestion  management  is  used  instead  of  the  simple  FIFO  queues.  Secondly,  demand 
signals  are  substituted  for  the  lERs.  The  lERs  are  a  simplified  form  of  demand  signal. 
JCSS  lERs  use  the  basic  type  of  service  field  as  described  in  Request  for  Comments 
(RFC)  791  instead  of  the  more  modem  and  expanded  Diffserv  field  defined  in  RFC  2474. 
The  demand  signals  allow  for  DSCP  marking,  a  critical  feature  for  this  study.  The 
message  size  and  inter-arrival  rates  are  specified  the  same  for  both  types  of  demand 
signals.  lERs  were  used  in  the  baseline  scenario  which  allows  the  use  of  Department  of 
Defense  Architecture  Framework  (DoDAF)  based  architectural  design  as  direct  inputs  to 
the  model.  The  QoS  policy  is  configured  on  the  shipboard  ADNS  router  at  the  outbound 
satellite  interface.  The  traffic  is  divided  into  two  different  types  of  traffic  that  are  based 

on  the  DifiBerv  service  classes  identified  in  Net  Centric  Implementation  Document 
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(NCID  T300).  The  traffic  flows  are  asymmetric  with  a  volume  in  excess  of  the  satellite 
link  capacity  flowing  from  ship-to-shore.  The  traffic  in  the  reverse  direction  does  not 
cause  any  network  congestion.  The  DSCP  value  assigned  to  the  medical  traffic  is 
assigned  to  a  service  class  in  one  of  the  CBWFQ  Scenarios.  Figure  28  illustrates  how  a 
CBWFQ  policy  works  (Figure  28  is  taken  from  JCSS  10.0  Code  of  Best  Practices). 


Incoming  Packets 


Outgoing  Packets 


Figure  28.  CBWFQ 

10.  Humanitarian  Mission  Results 


Table  10.  Application  Response  Time  in  seconds  (per  16  MB  transactions) 


Statistic 

Average 

Maximum 

Minimum 

3M  (seconds) 

2,012.11 

2,125.92 

1,949.05 

Admin  (seconds) 

4,045.42 

4,123.76 

3,969.57 

Medical  (seconds) 

1,987.64 

2,072.74 

1,894.53 

Messaging  (seconds) 

10,012.95 

10,063.45 

9,962.45 

Operations  (seconds) 

5,998.20 

6,063.12 

5,915.34 

Training  (seconds) 

4,019.54 

4,104.73 

3,867.74 

C.  ANALYSIS  OF  RESULTS 

The  results  of  the  simulation  conducted  within  the  JCSS  tool  show  the  potential 
for  applying  QoS  data  marking  to  affect  a  faster  throughput  of  prioritized  data  over  the 
baseline  network  configuration.  In  this  simulation,  the  CO  applied  a  higher  QoS  marking 
to  be  applied  to  medical  data,  thus  significantly  reducing  the  application  response  time 
from  4,003.92  seconds  to  1,987.64  seconds. 

In  steady  state  operations,  this  priority  is  not  a  big  concern.  However,  ships  lose 
connectivity  quite  frequently  and  may  only  experience  short  intermittent  periods  of 
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connectivity.  This  lack  of  connectivity  can  create  a  large  backlog  of  outbound  traffic. 
The  next  period  of  eonnectivity  may  not  last  long  enough  to  elear  the  baeklog.  It  is  in 
this  scenario  that  data  prioritization  beeomes  critical.  By  using  a  prioritization  matrix  to 
adjust  QoS  policies,  the  CO  can  dramatically  increase  the  probability  that  the  most 
mission  eritieal  data  gets  delivered  in  a  timely  fashion. 

The  applieations  response  times  under  the  QoS  eonfiguration  (see  Table  10) 
exhibit  preferred  treatment  of  the  prioritized  traffic.  These  results  demonstrate  the 
effectiveness  of  a  data  marking  QoS  strategy.  The  medical  data  traffic  was  assigned  a 
DSCP  value  of  AF21  while  the  other  application  messages  were  given  best  effort 
treatment.  The  AF21  (010010)  DSCP  value  is  low  packet  drop,  assured  forwarding 
traffic  classification.  The  AF21  router  queue  was  assigned  90%  of  the  available 
bandwidth  for  the  slot,  after  a  25%  reservation  for  router  overhead  traffie.  The  remaining 
10%  of  the  slot  bandwidth  was  allocated  to  the  rest  of  the  traffic.  At  the  simulated  traffic 
load,  congestion  was  not  prevalent  so  the  effeet  of  WRED  policy  was  not  demonstrated. 
Traffie  loads  were  not  increased  beyond  this  level  beeause  the  inereased  load  would  not 
be  representative  of  the  applieations  being  simulated  and  traffic  prioritization  vice 
congestion  management  was  the  focus  of  the  study. 
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IV.  CONCLUSIONS 


A,  CONCLUSIONS 

This  project  proved  that  data  marked  with  a  higher  priority  have  a  higher 
transmission  rate  when  placed  through  a  prioritized  queue.  Using  Extends imV'^’^ 
modeling  and  statistical  analysis,  the  reasonable  conclusion  could  be  drawn  that  the 
average  transmission  time  for  a  given  data  category  will  decrease  based  on  the  priority 
level  assigned  to  it  as  long  as  other  packets  exist  with  a  lower  priority.  Thus,  the 
prioritization  methodology  proposed  would  yield  improved  data  throughput  under 
congested  conditions. 


Figure  29.  Extends imV™  Simulation  Results 

The  figure  shows  the  simulation  results  of  the  ExtendSim?™  model  comparing  both  with 

no  prioritization  and  with  prioritized  data. 
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Simulating  the  shipboard  ADNS  infrastructure  using  JCSS,  it  was  determined  that 
the  size  and  periodicity  of  application  packets  would  not  cause  a  backlog  of  data  when 
the  ship  has  constant  connectivity.  In  other  words,  the  JCSS  simulation,  which  assumes 
ideal  shipboard  communication  conditions,  produced  no  congestion  in  the  data  categories 
of  interest  and  thus  no  throughput  improvements  were  realized.  This  was  consistent  with 
expectations  based  on  interviews  with  SMEs  and  others  having  knowledge  of  shipboard 
operations.  However,  ships  do  not  often  operate  under  ideal  communication  conditions. 
For  example,  ships  operating  in  high  concentration  areas  have  to  share  limited  satellite 
resources.  As  a  result,  ships  are  given  small  satellite  connectivity  windows  during  which 
time  environmental  factors  such  as  heavy  seas  or  adverse  weather  can  cause  periodic  loss 
of  connectivity.  Furthermore,  a  ship"s  mission  may  sometimes  necessitate  a  heading 
resulting  in  the  mast  or  superstructure  interfering  with  the  direct  line  of  sight  between  the 
antenna  and  satellite  thus  negatively  impacting  connectivity  while  this  situation  persists. 
Fosses  in  connectivity  on  a  regular  basis  result  in  a  backlog  of  data  waiting  to  get  off  the 
ship.  Therefore,  we  conclude  that  when  a  ship  is  under  intermittent  connectivity,  the 
implementation  of  data  marking,  prioritizing,  and  prioritized  queuing  would  effectively 
allow  COs  the  ability  to  get  their  highest  priority  data  off  their  ships  in  a  far  more 
effective  manner. 

B,  RECOMMENDATIONS  AND  AREAS  FOR  FURTHER  STUDY 

As  the  project  team  learned  during  the  stakeholders  and  need  analysis,  ship-to- 
shore  data  prioritization  is  an  important  subject  to  address.  In  fact,  the  Navy"s  technical 
community  has  been  trying  to  address  this  for  several  years  now.  Although  the  ADNS 
community  has  been  striving  to  improve  its  prioritization  capabilities  from  a  technical 
(implementation/solution)  standpoint,  a  higher  level  and  wider  effort  should  be 
undertaken  in  order  to  define  ship-to-shore  data  prioritization  requirements  from  a 
functional  perspective.  The  ADNS  community  seems  to  be  longing  for  this,  a 
“framework”,  as  one  of  the  stakeholders  described  it,  in  which  they  can  work  with.  Such 
an  effort  (e.g.,  stakeholders  functional  requirements  Integrate  Product  Team  (IPT))  would 
be  theater  wide,  bringing  in  elements  from  various  war  fighter  user  communities,  and 

eliciting  high  level  functional  requirements  from  them. 
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Based  on  the  results  of  the  theater  wide  stakeholders  funetional  requirements  IPX 
reeommended  above,  develop  the  user  interfaee  applieation  that  would  employ  the 
prioritization  matrix  deseribed  in  this  project.  This  would  give  the  CO  the  capability  to 
select  and  prioritize  data  based  on  the  ship"s  operational  situation,  before  the  data  leave 
the  ship. 

Another  recommendation  that  could  minimize  user  effort  and  improve  automation 
and  modularity  is  to  develop  an  automated  interface  service  for  the  network  to  receive 
prioritization  information  from  external  application  sources.  An  external  application 
example  is  the  user  interface  recommended  above.  This  service  would  translate  the 
prioritization  information  from  external  application  sources  into  QoS  policies  and  other 
mechanisms  to  actually  implement  prioritization  within  the  network.  This  service  would 
allow  modularity,  interoperability,  flexibility,  and  would  allow  dynamic  changes  in 
receiving  prioritization  information  from  various  sources  and  driving  the  network 
prioritization.  To  illustrate  the  need  for  this  automated  interface  service,  consider  the 
current  ADNS  prioritization  capability.  The  current  ADNS  prioritization  interface,  that 
which  receives  prioritization  information  from  the  user  for  the  network  to  employ,  is 
problematic.  This  is  the  main  reason  why  ADNS”  current  prioritization  capability  is  not 
widely  used. 

A  business  process  reengineering  may  have  to  be  conducted.  This  would 
eliminate  the  status  quo  in  which  prioritization  is  done  mainly  ashore  and  in  an  ad-hoc 
manner.  Once  the  framework  is  in  place  and  prioritization  is  fully  implemented  on  the 
ship,  performing  prioritization  ashore  also  could  cause  data  conflicts. 

As  discussed  during  the  project  meetings  between  the  team  and  its  advisors,  the 
work  that  have  been  started  in  this  project  and  the  recommendations  could  be  continued 
and  further  developed  by  other/future  NFS  masters  and/or  doctoral  efforts.  Such 
undertaking  could  continue  to  parallel  the  work  by  the  ADNS  and  IT  community  and 
would  benefit  the  Navy  as  a  whole. 
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APPENDIX  A.  ARCHITECTURE 


A.  ARCHITECTURE 

1.  Operational  Activity  Decomposition  Tree  (OV-5a) 

The  Capstone  Operational  Aetivity  Deeomposition  Tree  (OV-5a)  as  shown  in 
Figure  30  displays  the  eapabilities  and  aetivities  of  the  architeeture  organized  in  a 
hierarehal  structure.  The  OV-5a  helps  provide  an  overall  picture  of  the  activities 
involved  and  a  quick  reference  for  navigating  the  OV-5b.  Operational  activities  are 
derived  from  the  Universal  Naval  Task  List  (UNTL). 

The  OV-5  describes  the  operations  that  are  conducted  in  the  course  of  achieving  a 
mission  capability  from  a  typical  USN  afloat  vessel  underway.  The  operational  activities 
focus  on  the  activities  previously  shown  in  the  prioritization  matrix  (which  are  AD, 
JTMD,  strike,  NSFS,  MIO,  humanitarian  support,  MCM,  ASW,  SUW,  INTEL,  transit, 
and  off  station.  The  activities  are  further  decomposed  based  on  their  pedigree  in  the 
doctrinal  documents  previously  mentioned  in  this  paragraph. 


67 


A.1  Deploy  Forces/Cond 
Maneuver 

NTA1 

ict 

A.2  Develop  Intelligence 
NTA  2 

A.3  Employ  Firepower 
NTA  3 

A.4  Perform  Logistics  and  Combat  Service 
Support 
NTA4.0 


A1 .1  Move  Naval  Tactict  I 
Forces  -  Mine  counrtei 
measures  (MCM),  Trans 
NTA1.1 


St 


A1 .2  Conduct  Maneuver 
Close  Forces 
MCT1.3 


A2.1  Plan,  Direct  Intel  0|  i 
NTA  2.1 


A3.1  Attack 

NTA  3.2 


A4.1  Perform  Civil  Militar/ 
Engineering  Support 
NTA  4.7 


Capstone  Activity  Tree  Ver  3 
05  Node  Tree) 
System  Architect 
Sun  Sep  25,  2011  10:01 
- Comment - 


Draft  Captstone  OV-5A 
Huffman_Pinner_Rodericl’ 


A1.2.1  Conduct  Amphib  Ops 
MCT  1.3.2 


A2.1.1  Conduct  Production, 
Planning  and  Directing  (Ir  tel 
Collection) 

NTA  2.1.4 


A3. 1.1  Attack  En^my 
Targets  (Strike) 

NTA  3.2.1 


A3. 1.2  Intercept,  Engage  , 
Neutralize  Enemy  Alrcra 
Missile  Targets  (DCA) 
NTA  3.2.7 


ft 


A4.1.1  Provide  Humanitar 
Support 
NTA  4.7.8 


A1.2.1.1  Conduct  Marltlnn 
Interdiction  Operations  (hIK 
MCT  1. 3.2.8 


10) 


A3.1.1.1  Attack  Submerged 
Targets  (ASW) 

NTA 


A3.1 .1 .2  Attack  Surface 
Targets  (Surface  Warfani) 
NTA 


Figure  30.  Operational  Aetivity  Deeomposition  Tree  (OV-5a) 


The  OV-5  describes  the  operations  that  are 


conducted  in  the  course  of  achieving  a  mission  capability  from  a  typical  USN  afloat  vessel 
underway. 
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2,  Operational  Activity  Model  (OV-5b) 

The  Capstone  OV-5  Model  depicts  the  Joint  Capabilities  Area  (JCA)  in  the 
context  of  the  high  level  operational  activities  conducted  by  the  Ship.  The  focus  of  the 
model  is  the  routing  of  data  as  prioritized  by  the  operators  for  a  specific  mission.  This 
model  provides  the  framework  for  the  ship  conduct  of  JCAs  that  are  mapped  throughout 
this  model.  The  Ship  provides  the  Joint  Task  Force  (JTF)  Commander  with  the  following 
operational  capabilities:  force  support,  battlespace  awareness,  force  application, 
command  and  control,  net-centric  and  protection 

Inputs  and  outputs  of  operational  activities  relate  to  information  elements  of  the 
OV-3.  The  activities  identified  in  the  OV-5  are  also  directly  traceable  to  the  OV-3.  The 
activities  from  the  OV-5  relate  indirectly  to  the  functionality  of  the  ship  through  a 
mapping  of  activities  to  system  functions  derived  from  the  Joint  Common  System 
Function  List  (JCSFL).  Normally  this  association  is  contained  in  the  SV-5.  The  ship  will 
support  these  activities  by  either  automating  them  directly  or  by  supporting  them  by 
providing  automated  tools.  It  must  be  noted  that  the  activities  are  from  an  authoritative 
data  source,  specifically  the  naval  activity  list.  A  graphical  depiction  of  the  activity 
relationship  in  a  node  tree  and  then  in  Integration  Definition  (IDEFO)  format  is  provided. 
The  activity  model  context  diagram  is  provided  in  Figure  31  and  the  IDEFO 
decomposition  down  to  the  leaf  level  activities  are  also  provided  in  Figure  32  and  Figure 
33. 
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Figure  3 1 .  A-0  Context  Diagram 
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Figure  32.  AO  Decomposition  Diagram 
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Figure  33.  Leaf  Level  Aetivity  Deeompostion 

5,  Operational  Information  Exchange  Matrix  (OV-3) 

The  information  exehanged,  oharaeteristies,  and  assoeiated  aetivities  performed 
by  the  ship  that  support  the  JCA  are  outlined  within  the  OV-3. 

The  ship  OV-3  identifies  information  elements  and  relevant  attributes  of  the 
information  exehanged  while  providing  aetivities  for  JCAs;  then,  assoeiates  the 
information  exehanges  to  the  produeing  and  eonsuming  operational  nodes  for  the 
aetivities  to  the  need-line  that  the  exehange  is  transmitted  upon.  The  OV-3  doeuments 
the  information  exehanged  and  the  eharaeteristies  (deseription,  attributes,  seeurity,  ete.) 
for  eaeh  of  the  exehanges.  The  OV-3  details  information  exehanges  and  identifies  “who 
exehanges  what  information,  with  whom,  why  the  information  is  neeessary,  and  how  the 
information  exchange  must  occur.”  [CJCSI  6212. OIL,  2008].  There  is  not  a  one-to-one 
mapping  of  OV-3  information  exchanges  to  OV-2  need-lines;  rather,  many  individual 
information  exchanges  are  associated  with  one  need-line.  The  OV-3  identifies 
information  elements  and  relevant  attributes  of  the  information  exchange  associated  with 
a  need-line  between  producing  and  consuming  operational  nodes  in  the  OV-2  while 
conducting  activities  contained  within  the  OV-5. 
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Figure  34.  Operational  Information  Exchange  Matrix  (OV-3) 
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Figure  35.  Operational  Information  Exehange  Matrix  (OV-3) 
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6,  Capability  to  Operational  Activities  Mapping  (CV-6) 

The  Capability  to  Operational  Activities  Mapping  (CV-6)  identifies  capabilities 
and  the  associated  operational  activities  required  for  a  typical  USN  afloat  vessel 
underway  and  in  port.  In  order  to  understand  the  information  exchanges  and  related 
services  that  describe  information  sharing  capabilities,  a  CV-6  As-Is  and  CV-6  To-Be 
view  was  developed.  The  As-Is  view  depicts  the  current  state  of  a  typical  USN  afloat 
vessel  underway  and  in  port  and  the  To-Be  view  depicts  the  future  once  a  prioritization 
scheme  is  incorporated  into  a  typical  USN  afloat  vessel  underway  and  in  port. 

The  operational  activities  shown  are  derived  from  the  mission  areas  that  the  ship 
will  participate  in  and  are  sourced  from  the  UNTL  publications.  The  capabilities  are 
sourced  from  the  JCA  dated  January  12,  2009.  The  JCAs  are  Department  of  Defense 
(DoD)  capabilities  functionally  grouped  to  support  capability  analysis,  strategy 
development,  investment  decision  making,  capability  portfolio  management,  and 
capabilities-based  force  development  and  operational  planning.  An  “X”  in  the  cell 
indicates  that  full  functionality  is  provided,  supporting  the  activity.  A  blank  cell  indicates 
that  there  is  no  capability  support  planned  for  an  operational  activity,  or  that  a 
relationship  does  not  exist  between  the  operational  activity  and  the  capability. 
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Table  1 1 .  Capability  to  Operational  Aetivities  Mapping  (CV-6)  As-Is 


Activities 

Capabilities 

A3. 1.2  Intercept, 
Engage,  Neutralize 
Enemy  Aircraft 
Missile  Tragets  -Air 
Defense  (AD)  & 
JTMD 

NTA  3.2.7 

strike 

NTA  3.2.1 

A3. 1.3  Coduct 

Fire  Support- 

Naval  Surface 
Fire  Support 
(NSFS) 

Al.2.1.1  Conduct 

Maritime 

Interdiction 
Operations  (MIO) 
MCTl.3.2.8 

Al.l  Move  Naval 

Tactical  Forces- 

Mlne  Counter 

Measures  (MCM), 
Transist 

NTA  1.1 

A3.1.1.1  Attack 

Submerged 
Targets  (ASW) 
NTA  3.2.1.2 

A3.1.1.2  Attack 
Surface  Targets 
(Surface 
Warfare)  NTA 
3.2.1.1 

Humanitarian 

Operations 

NTA  4.7.8 

A2.1.1 

Conduct 

Production, 
Planning  and 

Direction 

(Intelligence 

Collecton 

(INTEL) 

NTA  2.1.4 

1.0  Force  Support 

1.1  Force  Management 

X 

X 

X 

X 

X 

X 

X 

X 

X 

1.2  Force  Preparation 

X 

2.0  Battlespace 

Awareness 

2.1  Intelligence,  Surveillance  and 

Reconnaissance 

X 

2.2  Environment 

X 

X 

X 

X 

3.0  Force 
Application 

3.2  Engagement 

X 

X 

X 

X 

X 

3.1  Maneuver 

X 

X 

X 

X 

X 

X 

4  Logistics 

4.1  Deployment  and  Distribution 

X 

X 

X 

X 

5.0  Command  & 

Control 

5.2  Understand 

X 

X 

X 

X 

X 

X 

X 

X 

5.3  Planning 

X 

X 

X 

X 

X 

X 

X 

X 

5.4  Decide 

X 

X 

X 

X 

X 

X 

X 

X 

5.5  Direct 

X 

X 

X 

X 

X 

X 

X 

X 

5.6  Monitor 

X 

X 

X 

X 

X 

X 

X 

X 

6.0  Net-Centric 

6.1  Information  Transport  (IT) 

X 

X 

X 

X 

X 

X 

X 

X 

6.2  Enterprise  Services  (ES) 

X 

X 

X 

X 

X 

X 

X 

X 

6.3  Information  Assurance 

X 

X 

X 

X 

X 

X 

X 

X 

7.0  Protection 

7.1  Prevent 

X 
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Table  12.  Capability  to  Operational  Activities  Mapping  (CV-6)  To-Be 


Activities 

Capabilities 

A3. 1.2  Intercept, 
Engage,  Neutralize 
Enemy  Aircraft 
Missile  Tragets  -Air 
Defense  (AD)  & 
JTMD 

NTA  3.2.7 

strike 

NTA  3.2.1 

A3.1.3  Coduct 
Fire  Support- 

Naval  Surface 
Fire  Support 
(NSFS) 

Al.2.1.1  Conduct 

Maritime 

Interdiction 
Operations  (MIO) 

MCT  1.3.2.8 

Al.l  Move  Naval 

Tactical  Forces- 

Mine  Counter 

Measures  (MCM), 
Transist 

NTA  1.1 

A3.1.1.1  Attack 

Submerged 
Targets  (ASW) 

NTA  3.2.1.2 

A3. 1.1.2  Attack 
Surface  Targets 
(Surface 
Warfare)  NTA 

3.2.1.1 

Humanitarian 

Operations 

NTA  4.7.8 

A2.1.1 

Conduct 

Production, 
Planning  and 
Directiong 
(Intelligence 
Collecton 
(INTEL) 

NTA  2.1.4 

1.0  Force  Support 

1.1  Force  Management 

X 

X 

X 

X 

X 

X 

X 

X 

1.2  Force  Preparation 

X 

2.0  Battlespace 

Awareness 

2.1  Intelligence,  Surveillance  and 
Reconnaissance 

X 

2.1. 1.1  Define  and  Prioritize 
Intelligence,  Surveillance  and 
Reconnaissance  Requirements 

X 

2.2  Environment 

X 

X 

X 

X 

3.0  Force 

Application 

3.2  Engagement 

X 

X 

X 

X 

X 

3.1  Maneuver 

X 

X 

X 

X 

X 

X 

5.0  Command  & 

Control 

5.2  Understand 

X 

X 

X 

X 

X 

X 

X 

X 

5. 1.2.5  Establish  Commander's 

Expectations 

X 

X 

X 

X 

X 

X 

X 

X 

5.3  Planning 

X 

X 

X 

X 

X 

X 

X 

X 

5.4  Decide 

X 

X 

X 

X 

X 

X 

X 

X 

5.5  Direct 

X 

X 

X 

X 

X 

X 

X 

X 

5. 5. 1.2  Issue  Priorities 

X 

X 

X 

X 

X 

X 

X 

X 

5.6  Monitor 

X 

X 

X 

X 

X 

X 

X 

X 

6.0  Net-Centric 

6.1  Information  Transport  (IT) 

X 

X 

X 

X 

X 

X 

X 

X 

6.2  Enterprise  Services  (ESj 

X 

X 

X 

X 

X 

X 

X 

X 

6.3  Information  Assurance 

X 

X 

X 

X 

X 

X 

X 

X 

6. 3.1.2  Rapid  Configuration  Change 

X 

X 

X 

X 

X 

X 

X 

X 

7.0  Protection 

7.1  Prevent 

X 

9.0  Corporate 
Management  and 
Support 

9.2  Strategy  and  Assessment 

X 

X 

X 

X 

X 
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7,  Systems  Interface  Description  (SV-1) 

The  Systems  Interfaee  Description  (SV-1)  depicts  systems  nodes  and  the  systems 
resident  at  these  nodes  to  support  organizations/human  roles  represented  by  operational 
nodes  of  the  Operational  Node  Connectivity  Description  (OV-2).  SV-1  also  identifies  the 
interfaces  between  systems  and  systems  nodes. 

SV-1  graphical  depiction  shown  below  provides  an  overview  of  the  systems  and 
identifies  the  resource  flows  from  a  typical  USN  afloat  vessel  underway  and  in  port.  As 
in  the  OV-2,  it's  understood  that  these  generic  nodes  might  actually  breakout  into 
multiple  nodes  however  to  reduce  the  time  required  for  research  and  the  overall 
complexity  of  the  SV-1  the  decision  was  made  to  use  generic  subject  nodes. 

Two  SV-1  views  were  developed;  a  SV-1  As-ls  and  SV-1  To-Be.  The  As-ls  view 
depicts  the  current  state  of  a  typical  USN  afloat  vessel  underway  and  in  port  and  the  To- 
Be  view  depicts  the  future  once  a  prioritization  scheme  is  incorporated  into  a  typical  USN 
afloat  vessel  underway  and  in  port. 

The  black  box  depicts  the  focus  of  the  capstone  projects  the  will  prioritize  data 
before  entering  the  ADNS. 
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Figure  37.  Systems  Interfaee  Deseription  (SV-1)  As-Is 
SV-1  identifies  the  interfaces  between  systems  and  systems  nodes. 
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Figure  38.  Systems  Interfaee  Deseription  (SV-1)  To-Be 
SV-1  identifies  the  interfaces  between  systems  and  systems  nodes. 
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APPENDIX  B.  MODELING  AND  SIMLUATION 


Figure  39.  Priority,  Size,  and  Data  Types  Assigned 
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Table  13.  Data  collected  for  no  priority  applied 


No  priority  applied  -  Transmission  time  Data  for  100  runs 
First  In  -  First  Out 


ENG 

ADMIN 

MED 

TRNG 

MSG 

3M 

OPS 

Data  Type 

Data 

Data 

Data 

Data 

Data 

Data 

Data 

13.455 

14.684 

7.152 

6.836 

15.785 

12.372 

7.535 

2.897 

7.404 

7.124 

2.259 

4.582 

1.988 

2.136 

19.287 

12.407 

12.811 

13.232 

14.057 

17.499 

18.050 

5.252 

4.555 

8.165 

18.499 

5.722 

3.685 

3.323 

34.160 

34.849 

34.735 

29.736 

29.969 

33.809 

31.648 

34.522 

33.060 

30.328 

33.923 

33.043 

36.199 

35.111 

17.881 

17.737 

16.627 

16.210 

16.768 

18.142 

17.717 

3.200 

2.959 

0.895 

3.045 

3.015 

3.410 

3.481 

44.325 

44.276 

44.314 

44.915 

43.339 

44.999 

44.078 

19.693 

20.442 

19.782 

20.873 

21.078 

21.071 

20.991 

29.497 

30.284 

29.627 

29.436 

26.373 

28.563 

28.912 

32.125 

31.640 

31.768 

32.370 

32.577 

34.626 

34.423 

4.517 

1.674 

3.782 

4.279 

1.617 

1.051 

2.172 

24.557 

21.017 

27.691 

21.378 

20.229 

22.561 

22.880 

22.868 

17.765 

17.640 

18.785 

18.738 

24.100 

18.373 

3.207 

2.597 

3.818 

3.646 

2.408 

1.594 

3.865 

6.915 

7.519 

6.782 

6.861 

7.268 

6.991 

7.289 

26.791 

29.458 

29.144 

30.212 

26.684 

26.493 

28.685 

5.649 

7.359 

7.423 

8.383 

7.333 

6.396 

6.184 

12.824 

12.776 

12.115 

11.617 

11.784 

12.333 

12.319 

42.072 

40.576 

41.773 

40.900 

41.493 

41.840 

42.464 

35.218 

34.416 

31.773 

32.696 

38.158 

32.119 

33.597 

19.842 

18.092 

18.661 

16.626 

16.950 

18.094 

14.853 

25.293 

23.293 

24.499 

25.257 

23.508 

25.309 

26.106 

2.876 

1.914 

1.419 

1.916 

2.285 

1.104 

1.096 

18.040 

18.687 

19.701 

22.153 

19.318 

19.583 

18.220 

7.684 

5.969 

8.302 

5.835 

6.134 

7.487 

6.794 

4.059 

3.910 

6.145 

4.493 

3.497 

2.470 

4.990 

30.529 

21.438 

29.656 

28.314 

29.463 

28.289 

30.434 

22.238 

22.840 

15.378 

15.367 

21.490 

22.892 

21.684 

3.605 

5.906 

3.956 

5.062 

4.714 

4.402 

5.525 

23.009 

30.040 

31.361 

31.644 

32.152 

30.485 

23.878 

9.007 

8.749 

9.232 

7.854 

5.309 

8.955 

8.520 

35.379 

34.695 

34.658 

34.716 

34.495 

34.036 

35.124 

28.845 

29.412 

29.582 

29.047 

30.448 

29.637 

28.919 
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21.542 

22.413 

19.672 

21.386 

22.582 

19.403 

20.558 

15.388 

16.271 

12.371 

14.213 

13.773 

14.625 

13.341 

35.776 

37.857 

37.524 

36.220 

37.075 

37.357 

37.326 

20.884 

22.007 

21.528 

22.054 

21.985 

19.808 

21.430 

17.211 

19.188 

18.087 

19.313 

17.120 

18.825 

17.655 

29.905 

29.029 

30.904 

30.328 

30.777 

30.017 

30.379 

23.570 

24.273 

23.909 

19.849 

20.633 

24.177 

21.325 

0.691 

2.298 

0.913 

2.499 

0.903 

2.511 

1.757 

15.279 

16.836 

12.598 

14.531 

14.776 

11.852 

16.033 

3.953 

1.500 

1.645 

0.688 

1.159 

3.110 

3.524 

9.793 

8.487 

8.370 

9.069 

7.935 

8.857 

9.151 

12.476 

11.387 

11.215 

12.282 

11.977 

13.618 

8.766 

6.818 

8.496 

13.124 

8.444 

7.900 

7.584 

7.997 

25.019 

25.476 

25.120 

25.101 

26.667 

27.565 

25.518 

18.364 

21.386 

22.071 

21.469 

26.316 

20.397 

19.460 

23.520 

22.541 

24.242 

23.697 

23.654 

23.022 

22.295 

22.487 

22.966 

21.042 

21.556 

17.919 

22.705 

18.143 

15.325 

14.485 

10.756 

14.083 

16.672 

15.620 

16.401 

22.735 

22.661 

19.708 

22.462 

17.667 

24.007 

24.298 

8.875 

8.281 

7.996 

7.434 

8.056 

9.397 

6.685 

22.384 

21.842 

24.079 

21.756 

22.913 

22.474 

22.320 

9.020 

7.284 

7.167 

9.150 

7.704 

6.032 

6.622 

13.881 

11.463 

11.416 

11.632 

14.442 

12.108 

15.174 

12.393 

10.162 

10.905 

10.168 

12.371 

9.438 

11.633 

10.354 

13.096 

12.581 

13.902 

11.199 

13.747 

9.624 

20.017 

12.946 

20.654 

11.214 

13.659 

12.516 

12.155 

41.681 

40.698 

41.441 

40.733 

37.063 

29.807 

40.958 

5.888 

5.127 

5.996 

5.486 

6.072 

12.573 

6.404 

19.876 

21.364 

18.198 

22.665 

18.907 

20.256 

20.875 

11.292 

9.895 

12.978 

13.866 

11.861 

13.122 

8.628 

36.215 

35.051 

35.009 

32.089 

38.125 

38.750 

38.518 

8.010 

8.571 

9.366 

9.845 

3.652 

8.124 

8.007 

21.946 

24.435 

23.987 

23.147 

23.053 

28.520 

23.910 

9.674 

11.606 

10.694 

12.178 

10.639 

10.869 

12.242 

22.499 

20.747 

21.907 

22.740 

19.946 

21.950 

20.555 

43.321 

40.879 

42.817 

36.240 

40.279 

43.214 

40.377 

29.169 

29.436 

29.173 

26.444 

28.312 

25.422 

28.769 

26.916 

30.929 

28.949 

25.923 

30.007 

30.656 

30.331 

3.204 

1.864 

0.778 

1.038 

0.898 

6.843 

0.971 

37.987 

39.270 

37.512 

37.119 

44.844 

36.134 

39.092 
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19.509 

18.343 

19.726 

21.134 

20.127 

21.841 

19.543 

1.063 

1.940 

1.249 

0.977 

1.236 

1.323 

2.056 

23.740 

24.959 

19.500 

23.643 

23.363 

24.185 

23.637 

10.065 

6.565 

8.088 

8.741 

7.658 

5.981 

7.947 

6.560 

9.960 

8.392 

9.733 

9.515 

6.462 

5.137 

10.402 

9.246 

9.725 

9.301 

10.918 

11.370 

11.414 

29.437 

28.760 

26.811 

25.052 

28.114 

30.674 

30.036 

7.327 

7.580 

6.133 

8.178 

3.790 

8.520 

6.415 

39.877 

41.946 

37.856 

39.397 

41.583 

40.883 

42.344 

16.540 

26.432 

27.179 

26.187 

27.464 

24.169 

27.614 

9.861 

10.497 

8.905 

9.432 

8.332 

8.450 

9.338 

3.105 

1.018 

2.734 

10.701 

4.599 

3.994 

2.935 

40.173 

39.147 

37.491 

40.632 

37.969 

38.683 

40.126 

10.511 

4.237 

11.395 

10.878 

11.011 

9.960 

7.401 

7.519 

7.596 

8.188 

8.632 

8.367 

8.455 

7.680 

21.170 

21.467 

22.132 

22.169 

21.499 

21.402 

21.873 

6.326 

5.848 

5.513 

5.792 

3.318 

5.597 

6.125 

3.532 

6.146 

3.254 

2.605 

4.356 

4.260 

2.354 

21.918 

21.914 

22.498 

22.021 

23.293 

22.568 

22.825 

7.509 

8.093 

6.739 

5.309 

4.549 

5.939 

4.997 

3.424 

3.839 

3.801 

1.286 

3.097 

3.223 

2.043 

4.220 

1.804 

2.135 

0.894 

2.560 

1.050 

4.133 

24.830 

25.981 

25.038 

22.219 

24.265 

25.734 

25.276 

38.177 

37.653 

38.449 

38.357 

38.882 

40.215 

39.086 

13.736 

13.083 

16.498 

13.245 

10.800 

13.604 

12.276 

Average 

Trans 

time 

18.072 

17.930 

17.856 

17.789 

17.739 

18.101 

17.752 
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Table  14.  Data  collected  for  priority  sorting 


Priority  sorting  -  Transmission  time  Data  for  100  runs 


ENG 

ADMIN 

MED 

TRNG 

MSG 

3M 

OPS 

Data  Type 

Data 

Data 

Data 

Data 

Data 

Data 

Data 

Priority 

1 

2 

3 

1 

2 

3 

1 

1.494 

4.739 

16.589 

1.045 

1.440 

26.929 

1.797 

1.442 

5.883 

159.140 

2.258 

4.492 

172.838 

2.389 

3.121 

1.786 

48.653 

1.124 

2.826 

72.410 

2.449 

2.037 

10.900 

78.739 

1.195 

4.238 

94.803 

3.029 

1.284 

11.037 

42.868 

1.387 

1.582 

43.491 

1.443 

2.608 

3.449 

25.323 

3.589 

4.203 

25.704 

4.156 

1.687 

2.584 

56.462 

1.874 

2.689 

46.081 

2.197 

1.253 

1.051 

30.557 

2.220 

1.641 

29.322 

1.196 

1.204 

3.753 

84.519 

1.664 

5.961 

77.277 

1.232 

2.159 

1.077 

17.466 

1.811 

2.639 

17.627 

2.395 

1.156 

1.620 

4.245 

1.496 

0.902 

1.093 

1.813 

1.843 

2.008 

15.695 

1.681 

2.358 

15.841 

0.806 

1.612 

2.000 

123.662 

0.990 

1.568 

121.734 

1.296 

1.976 

7.907 

87.692 

1.367 

6.411 

85.256 

2.098 

0.955 

0.776 

3.422 

1.566 

1.776 

6.677 

1.277 

2.041 

2.699 

111.371 

1.444 

2.954 

128.001 

1.164 

2.128 

1.414 

28.086 

1.194 

2.468 

29.295 

2.065 

1.582 

1.942 

50.259 

1.766 

1.368 

49.352 

1.488 

1.831 

1.178 

63.553 

1.321 

1.578 

71.041 

0.831 

1.263 

2.810 

26.641 

1.562 

1.545 

25.833 

2.079 

3.277 

3.527 

6.535 

2.956 

7.994 

5.238 

1.852 

0.945 

5.168 

98.589 

1.685 

1.681 

98.039 

1.046 

2.128 

1.916 

123.095 

2.182 

4.414 

124.172 

1.234 

2.000 

1.902 

1.432 

1.132 

0.962 

0.956 

1.081 

1.468 

4.313 

27.608 

1.018 

6.286 

8.921 

1.538 

1.635 

6.345 

45.278 

2.889 

5.908 

40.853 

1.373 

2.232 

3.309 

12.488 

1.293 

3.275 

13.194 

3.713 

1.408 

1.509 

66.977 

1.981 

0.861 

68.060 

1.848 

1.945 

10.075 

7.820 

3.157 

9.085 

1.991 

5.555 

2.595 

7.831 

61.996 

1.221 

2.932 

64.678 

2.743 

2.365 

2.984 

1.530 

1.451 

2.302 

3.569 

0.944 

1.131 

4.248 

34.474 

1.881 

6.059 

38.258 

2.547 

2.439 

1.638 

34.421 

1.716 

1.497 

36.495 

2.124 

1.500 

1.455 

41.430 

1.188 

1.164 

49.760 

1.991 

3.557 

5.719 

62.371 

4.344 

1.144 

62.908 

2.854 
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1.887 

12.613 

73.751 

2.673 

2.509 

72.180 

1.639 

1.720 

2.083 

36.201 

2.037 

2.371 

49.082 

0.562 

0.946 

1.378 

1.458 

0.970 

1.293 

2.495 

1.826 

2.470 

1.189 

95.666 

0.983 

5.225 

76.936 

0.877 

1.463 

2.417 

53.399 

1.422 

1.091 

46.111 

1.131 

1.283 

6.944 

33.628 

1.720 

1.534 

34.100 

1.558 

1.553 

6.622 

93.792 

1.122 

6.956 

78.903 

3.787 

0.949 

3.968 

101.826 

1.606 

5.194 

102.237 

1.882 

2.802 

1.562 

57.050 

0.808 

5.268 

64.447 

1.855 

2.278 

5.849 

82.390 

3.126 

3.014 

81.213 

2.325 

0.770 

1.085 

2.096 

2.127 

1.641 

4.205 

0.967 

2.022 

1.590 

48.488 

3.018 

1.868 

47.680 

1.827 

1.845 

1.086 

26.752 

1.254 

1.346 

26.704 

2.406 

1.484 

2.902 

167.749 

2.805 

1.705 

170.248 

1.850 

1.202 

3.525 

52.045 

1.534 

3.940 

52.259 

2.085 

1.781 

4.341 

35.548 

2.370 

3.626 

33.534 

2.163 

1.882 

10.119 

39.300 

1.244 

0.958 

39.636 

1.626 

2.224 

16.186 

154.801 

3.694 

10.641 

175.368 

1.630 

3.423 

1.579 

109.634 

1.379 

1.669 

101.278 

3.546 

2.058 

4.387 

72.724 

0.976 

6.463 

72.296 

1.101 

1.887 

1.543 

96.035 

1.121 

1.817 

98.951 

1.996 

2.576 

7.770 

14.351 

0.993 

5.314 

27.277 

1.692 

2.255 

1.036 

72.794 

1.048 

1.273 

68.644 

1.351 

1.300 

1.353 

2.944 

1.293 

1.367 

3.503 

1.213 

1.067 

4.442 

16.924 

3.768 

4.064 

31.799 

3.111 

1.722 

2.599 

44.456 

1.602 

3.548 

53.211 

1.603 

1.351 

1.659 

8.237 

1.537 

1.825 

7.991 

1.700 

1.223 

2.859 

1.261 

1.428 

1.467 

2.302 

1.236 

0.751 

1.740 

43.130 

2.083 

3.936 

41.788 

2.243 

1.826 

3.284 

30.700 

1.914 

5.210 

22.539 

2.303 

2.612 

7.789 

134.283 

1.449 

8.176 

68.995 

1.912 

1.648 

1.800 

3.603 

1.265 

1.485 

21.082 

2.039 

2.121 

3.035 

54.268 

1.829 

5.736 

57.279 

1.045 

3.321 

6.330 

56.576 

1.691 

5.308 

53.792 

2.049 

0.962 

9.759 

1.030 

2.361 

10.921 

2.961 

1.516 

2.480 

1.833 

36.483 

2.283 

3.248 

37.253 

1.302 

1.658 

5.470 

19.587 

4.586 

3.113 

19.358 

1.506 

2.112 

1.821 

22.794 

1.721 

3.024 

11.815 

1.600 

1.850 

4.298 

3.608 

2.538 

2.379 

0.624 

1.410 

1.544 

1.271 

1.036 

0.756 

3.436 

1.498 

1.833 
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2.301 

2.201 

2.896 

1.240 

5.545 

5.304 

2.241 

1.086 

2.234 

51.518 

0.941 

1.837 

48.580 

0.875 

1.550 

1.819 

18.145 

2.450 

6.604 

9.163 

2.120 

1.303 

3.327 

29.363 

1.341 

1.449 

33.396 

2.122 

1.660 

3.226 

41.763 

1.841 

2.279 

48.029 

1.218 

1.201 

0.645 

86.008 

1.336 

2.648 

79.602 

1.625 

1.702 

1.774 

93.174 

1.760 

1.881 

93.892 

2.047 

1.074 

2.458 

45.982 

2.165 

3.064 

57.693 

2.924 

1.546 

2.891 

54.002 

1.289 

3.925 

46.715 

0.892 

1.048 

7.349 

65.082 

2.822 

1.309 

68.002 

0.900 

1.577 

2.826 

107.523 

3.362 

2.904 

119.900 

1.298 

1.024 

1.747 

37.016 

1.918 

11.730 

37.350 

2.893 

1.405 

6.101 

57.312 

0.962 

2.076 

59.771 

2.069 

1.450 

2.554 

90.387 

2.827 

1.137 

90.721 

1.746 

1.992 

1.426 

54.237 

1.555 

4.492 

54.643 

2.053 

2.155 

5.437 

7.502 

2.366 

9.127 

8.874 

1.803 

1.677 

6.072 

63.960 

1.364 

5.143 

71.863 

1.782 

1.836 

1.729 

55.890 

1.269 

2.873 

59.179 

1.756 

1.859 

3.962 

17.743 

1.965 

5.446 

14.204 

1.873 

1.890 

5.907 

180.797 

1.304 

5.123 

158.914 

1.889 

1.518 

4.405 

63.572 

4.247 

3.144 

62.726 

1.557 

2.567 

2.719 

15.584 

1.210 

1.217 

6.551 

3.120 

1.830 

1.624 

2.470 

1.240 

0.894 

3.919 

1.812 

2.132 

3.786 

51.504 

1.833 

3.260 

51.218 

1.390 

1.713 

3.304 

27.715 

1.639 

3.286 

30.032 

2.429 

Average 

Trans 

time 

1.787 

3.772 

50.245 

1.830 

3.476 

50.415 

1.874 
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APPENDIX  C.  RISK  MANAGEMENT 


Integrated  Risk  Assessment 


Overall  risk  is  calculated  as 
medium  based  on  current 
assessments  and  the  depth  of 
the  complexities. 


Performance 

(P1)  Capstone  concept:  Ifthe  formulated  concept  does  not 
meet  adequate  Technology  Readiness  Level  (TRL),  then  the 
implementation  of  the  concept  must  be  rejected. 

(P1)  Mitigation:  Coordination  between  team  members  and 
stakeholders  is  essential  for  success.  Investmentto  improve 
the  TRL  level  by  stakeholders. 

(P2)Conceptimplementation:  Ifthe  capstoneconceptresu  Its 
in  substantia!  costs  to  achieve  implementation  or  ability  to 
understandthe  usage  of  prioritization,  then  users  will  not 
participate. 

(P2)  Mitigation:  Continued  research  of  current  concepts  are 
essential  to  identify  alternate  costs,  schedules,  and 
performances.  Explained  benefits  to  the  user  community  and 
stakeholders  to  encourage  maximum  usage. 

(P3)  System  Performance:  Ifanyuseris  allowed  complete 
control  over  a  scheduling  mechanism,  the  system  may  suffer 
starvation  problems  for  others. 

(P3)  Mitigation:  The  system  design  must  include  anti¬ 
starvation  heuristics  such  as  aging  priorities. 


Figure  40.  Integrated  Risk  Assessment  -  Performance 

Figure  shows  the  probability  and  impact  of  the  performance  measures  of  the  three  most 
likely  risks  [Risk  Management  Guide  for  DoD  Acquisition,  2006]. 
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APPENDIX  D:  KEY  TERMS 


Ad-hoc  -  a  set  up  with  a  particular  purpose 

Afloat  -  floating  on  top  of  water;  on  board  a  ship  at  sea 

Ashore  -  not  on  a  ship;  on  the  land 

Backlog  -  unfinished  work  that  must  be  dealt  with  before  any  advancement  can  be  made 

Baseline  -  the  standard  to  which  all  other  things  are  to  be  compared  with,  a  line  used  as  a 
basis  for  comparison 

Battle  space  -  the  location  of  fighting  on  a  large-scale 

Bottleneck  -  a  narrow  junction  that  slows  progress  and  causes  jams;  one  process  is 
slower  than  another  which  hinders  the  overall  process 

Box-plot  -  a  schematic  representation  that  graphically  illustrates  the  samplers  mean,  the 
upper  and  lower  quartiles  (the  box),  and  the  outliers  (whiskers). 

Bits  per  second  (bps)  -  the  transmission  of  bits,  either  a  binary  one  or  zero,  is 
sent/received  within  a  second 

Bus  -  a  path  for  the  transmission  of  computer  data  which  is  usually  done  from  a 
peripheral  device  to  the  central  processing  unit 

Byte  (B)  -  the  amount  of  computer  memory  to  store  a  single  character  that  is  a  group  of 
eight  bits 

Capability  -  the  ability  of  something/operator  to  accomplish  a  operation 

Ceteris  paribus  -  all  things  being  equal;  if  everything  being  considered  stays  the  same 

Cipher  -  a  code;  a  key  is  needed  to  decipher  the  code,  that  is  letters  are  replaced  with 
something  else  according  to  a  system 

Configuration  -  the  way  parts  are  arranged  to  fit  together,  the  interconnection  of 
software  and  hardware  components  in  a  computer  system;  spatial  arrangement 

Decomposition  -  break  apart  from  complex  to  simple;  broken  down  into  its  constituent 
parts;  separate 

Demodulator  -  extract  a  signal  from  a  radio  wave  carrier  that  contains  information 
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Depot  -  where  military  supplies  are  stored;  a  warehouse  that  stores  things 

Differentiate  -  finding  differences  between  things;  different  due  to  its  specialization  or 
modification;  mathematical  derivative 

Discrete  -  not  connected,  separate,  distinct,  unrelated;  a  variable  with  a  finite  value 

Domain  -  the  subjecf's  scope;  activity  in  an  area  for  which  someone  is  in  control  or 
ownership;  a  domain  name,  for  example,  ONLINE;  a  mathematical  function"s  possible 
values 

Enclave  -  a  group  that  operates  within  a  larger  group 

Enterprise  -  a  new  possibly  risky  venture;  a  mission  especially  one  of  some  scope  and 
complication 

High  level  -  elevated  participation 

Interface  -  where  pieces  of  equipment  meet;  where  physical  boundaries  interact  and 
affect  each  other  at  the  connection;  where  two  computer  devices  exchange  data  flow 

Infrastructure  -  the  foundation  for  any  system;  the  basic  level  within  a  complex 
organization 

Integrate  -  several  objects  combine  into  a  larger  whole;  incorporate;  amalgamate 

IPX  -  an  integrated  product  team  which  consists  of  talented  people  from  many  different 
disciplines  who  become  one  in  order  to  share  the  responsibility  of  work  on  a  new  product 

Latency  -  the  systems"  measureable  time  delays;  time  measured  in  a  network  is  usually 
concerned  with  how  much  time  a  data  packet  gets  from  one  point  to  another 

Lossy  -  a  network  link  that  is  characterized  by  high  packet  drop  rate  and  or  data 
transmission  errors  due  to  unreliable  and  intermittent  connectivity 

Mega  (M)  -10^6,  1,000,000,  a  million 

Mini  -  10^-3,  .001,  one  thousandth 

Model  -  The  representation  of  a  system  to  be  analyzed  with  assumptions  on  how  the 
system  works;  a  microcosm  of  mathematical  and  logical  relationships  within  said  model; 
a  replica  to  gain  understanding  about  how  the  system  behaves. 
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Modulator  -  uses  a  baseband  input  signal  that  is  transformed  into  a  radio  frequeney  or 
modulated  signal 

Needline  -  a  line  on  an  arehiteetural  drawing  between  two  nodes  that  supplies  neeessary 
information  for  the  flow  of  serviees 

Net-centric,  or  netcentric  -  a  continuously  evolving  and  complex  community  of 
participants  who  have  a  shared  vision  of  mission  solutions  that  result  in  a  capability  that 
is  greater  than  the  sum  of  its  parts 

P-value  -  the  statistical  probability  of  obtaining  a  similar  data  set  or  worse  when  the  null 
hypothesis,  Hq,  is  true 

Pairwise  comparison  -  each  entry  is  compared  with  the  others  in  order  to  determine  its 
ranking  within  a  group 

Prioritization  -  maximize  success  by  arranging  things  in  the  order  of  importance 

Protocol  -  a  digital  message  format  system  that  enables  telecommunication  between 
computer  systems;  network  etiquette 

Prototype  -  an  original  model  built  to  test  a  concept  and  learn  improvements  in  its  class 
for  later  stages 

Quality  of  service  -  managing  the  problems  inherent  to  the  Internet  and  other  networks 
that  cause  jitter,  delay,  packet  loss,  and  bandwidth  availability  problems  in  a  cost 
effective  manner 

Quench  -  an  induced  delay  through  Internet  control  message  protocol  (ICMP)  to 
decrease  the  traffic  rate  of  data  messages  sent  to  an  Internet  host  destination 

Queue  -  a  waiting  line;  a  first  in  first  out  sequence 

Re-engineer  -  trouble-shooting  that  requires  redesign 

Scenario  -  a  collage  of  a  series  of  actions;  a  proposed  plan  is  outlined 

Scope  -  the  range  of  view  where  context  values  are  associated  with  in  an  area 

Simulation  -  is  the  use  of  a  computer  to  evaluate  a  model  (see  model)  by  running  data 
through  the  simulation  in  order  to  see  the  true  characteristics  of  the  model  without 
actually  building  the  model 

Storyboard  -  a  series  of  sketches;  a  primitive  “blueprint”  outlining  a  sequence  of  actions 
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Stove-pipe  -  one  explicit  application  that  very  efficiently  solves  an  issue 

Subnet  -  abbreviated  form  of  subnetwork,  where  a  logical  grouping  of  connected  device 
nodes  are  in  close  proximity  to  each  other;  a  separate  part  of  the  organizations  network 

Summits  -  one  centralized  event;  the  highest  level  one  can  achieve 

Systems  engineering  -  “Systems  engineering  is  an  interdisciplinary  approach  and  means 
to  enable  the  realization  of  successful  systems,”  states  the  International  Council  of 
Systems  Engineering  (INCOSE). 

Template  -  a  pattern  used  as  a  guide  to  create  something,  a  quick  method  to  define 
projects”  parameters  or  algorithms  that  are  repeatable 

Theater  -  war  zone 

Throttling  -  Used  in  network  engineering  as  a  traffic  technique  whereby  the  bandwidth 
is  constricted  by  controlling  package  flow  rates  in  order  to  minimize  congestion 

Trade-off  -  all  outcomes  could  not  be  obtained  at  the  same  time  so  one  thing  was 
exchanged  for  another  to  achieve  a  balance  between  risk  and  return 

Tukey  method  -  John  Tukey  is  the  statistician  who  invented  the  box-and-whisker  plot  of 
the  quartile  values.  The  Tukey  method  simultaneously  considers  all  possible  pairwise 
differences  of  the  means. 

Validation  -  officially  sanctioned;  the  act  of  being  valid  as  defined  in  user 
documentation  and  requirements 

“Vee”  -  the  letter  V 

Verification  -  the  act  of  proving  accuracy  with  a  test 

Web  browsing  -  using  a  web  browsef's  software  to  display  contents  on  the  World  Wide 
Web 


98 


LIST  OF  REFERENCES 


Agrawal,  Dharma  Prakash  and  Quing-An  Zeng.  Introduction  to  Wireless  and  Mobile 
Systems.  Stamford,  Connecticut;  Cengage  Learning,  201 1. 

Blanchard,  Benjamin  S.  and  Wolter  J.  Fabrycky.  Systems  Engineering  and  Analysis. 
Upper  Saddle  River,  New  Jersey:  Pearson  Prentice  Hall,  2006. 

Chairman  of  the  Joint  Chiefs  of  Staff  Instruction  (CJCSI)  6212.01  E:  Interoperability 
and  Supportability  of  Information  Technology  and  National  Security  Systems.  December 
15,2008.  Published  online  at 

http://www.dtic. mikcics  directives/cdata/unlimit/6212  01. pdf 

Chairman  of  the  Joint  Chiefs  of  Staff  Instruction  (CJCSI)  3170.01  G:  Joint  Capabilities 
Integration  and  Development  System.  March  1,  2009.  Published  online  at 
http://iitc.fhu.disa.mil/iitc  dri/pdfs/3170  Olg.pdf 

Chairman  of  the  Joint  Chiefs  of  Staff  Instruction  (CJCSI)  3470.01:  Rapid  Validation  and 
Resourcing  of  Joint  Urgent  Operational  Needs  (JUONS)  in  the  Year  of  Execution.  July 
9,  2007.  Published  online  at 

http://www.dtic.mil/cics  directives/cdata/unlimit/3470  01  .pdf 

Chairman  of  the  Joint  Chiefs  of  Staff  OPNA  VA  VINST  3500. 38B/MC03500. 26A/USCG 
COMDTINST  3500.IB:  Universal  Naval  Task  List  (UNTL)  Version  3.0.  January  30, 
2007.  Published  online  at 

http://www.uscg.mil/hq/cg5/cg513/docs/UNTL  ver  3.0  Jan  07.pdf 

Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS).  CJCSM  3500.04  F:  Universal  Joint  Task 

List  (UJTL).  June  1,  201 1.  Published  online  at 

http ://www. dtic.mil/ci cs  directives/cdata/unlimit/m3 5 0004 .pdf 

Dam,  Steven  H.  DoD  Architecture  Framework:  A  Guide  to  Applying  System 
Engineering  to  Develop  Integrated,  Executable  Architectures .  Marshall,  Virginia; 

SPEC,  2006. 

The  Department  of  Defense  Architecture  Framework  (DoDAF)  Version  1.5  Volume  I. 
April  23,  2007.  Published  online  at 
http://cionii.defense.gov/docs/DoDAF  volume  l.pdf 

The  Department  of  Defense  Architecture  Framework  (DoDAF)  Version  1.5  Volume  IT 
April  23,  2007.  Published  online  at 
http://cionii.defense.gov/docs/DoDAF  Volume  ILpdf 


99 


The  Department  of  Defense  Architecture  Framework  (DoDAF)  Version  2. 0.  May  28, 
2009.  Published  online  at  https://www.us.amiv.mil/suite/page/454707  and 
http://iite.fhu.disa.mil/iite  dri/pdfs/dodaf  v2vl.pdf. 

The  Department  of  the  Navy.  Common  Information  Element  List  (CIEL)  Version  2.0. 
September,  2007. 

The  Department  of  Defense.  Defense  Acquisition  Guidebook.  July  29,  2011  (This  is  a 
living  doeument  whieh  is  eontinuously  revised).  Published  online  at 
http://at.dod.mil/does/DefenseAequisitionGuidebook.pdf. 

The  Department  of  Defense.  Department  of  Defense  Direetive  (DoDD)  5000.01:  The 
Defense  Acquisition  System.  November  20,  2007.  Published  online  at 
http://www.dtie.mil/whs/direetives/corres/pdf/500001p.pdf. 

The  Department  of  Defense.  DoD  5000.2-R:  Mandatory  Procedures  for  Major  Defense 
Acquisition  Programs  (MDAPS)  and  Major  Automated  Information  Systems  (MAIS) 
Acquisition  Programs.  April  5,  2002.  Published  online  at 
http://www.acq.osd.mil/ie/bei/pm/ref-hbrarv/dodi/p50002r.pdf. 

The  Department  of  Defense.  Department  of  Defense  Instmction  (DoDI)  5000.02: 
Operation  of  the  Defense  Acquisition  System.  December  8,  2008.  Published  online  at 
http://www.dtic.mil/whs/directives/corres/pdf/500002p.pdf. 

The  Department  of  Defense.  Joint  Capability  Area  Management  System  (JCAMS). 
November  29,  2010.  Published  online  at  http://icams.penbavmedia.com/. 

The  Department  of  Defense.  Logistics  Joint  Capability  Areas  (JCAs).  June  8,  2009. 
Published  online  at  https://acc.dau.mil/CommunitvBrowser.aspx?id=288874&lang=en- 
US. 

The  Department  of  Defense.  Risk  Management  Guide  for  DoD  Acquisition.  Sixth 
Edition/Version  1.0.  August,  2006.  Published  online  at 
http://www.dau.mil/pubs/gdbks/docs/RMG%206Ed%20Aug06.pdf. 

The  Department  of  Defense.  Technology  Readiness  Assessment  (TRA)  Deskbook.  July, 
2009.  Published  online  at 

http://www.dod.gov/ddre/doc/DoD  TRA  July  2009  Read  Version.pdf. 

Dugan,  K.  “Navy  Mission  Planner.”  Master's  thesis.  Naval  Postgraduate  School,  2007. 
Eahie,  E.  In  discussion  with  Bradley  May,  August  4,  201 1 . 

Grady,  Jeffrey  O.  System  Synthesis:  Product  and  Process  Design.  Boca  Raton,  Elorida: 
CRC  Press,  2010. 


100 


Harding,  D.  In  discussion  with  Bradley  May,  August  10,  201 1 

Hayter,  Anthony  J.  Probability  and  Statistics  for  Engineers  and  Scientists.  Belmont, 
California:  Thompson  Higher  Education,  2007. 

IBM.  Telelogic  System  Architect  Version  11.2  User  Guide.  November  3,  2008. 
Published  online  at 

http://publib.boulder.ibm.eom/infoeenter/rsdp/vlrOmO/index.isp?topie=/eom.ibm.help.do 

wnload.sa.doe/topies/sa  versionll  2.html. 

IBM.  Rational  System  Architect  User  Guide  Version  1 1.4.  April  29,  201 1.  Published 
online  at  http://publib.boulder.ibm.eom/infoeenter/rsvsareh/vl  1/index. jsp. 

Keshav,  S.  “Congestion  Control  in  Computer  Networks.”  Master's  thesis.  University  of 
California,  1991. 

Law,  Averill  M.  Simulation  Modeling  and  Analysis.  New  York,  New  York:  McGraw- 
Hill,  2007. 

Maier,  Mark  W.  and  Eberhardt  Rechtin.  The  Art  of  System  Architecting.  Boca  Raton, 
Elorida:  CRC  Press,  2009. 

Morris,  M.  In  diseussion  with  Bradley  May,  September  19,  201 1. 

Naval  Postgraduate  School.  Notes  for  SE4003  (Software  Programming,  Paradigms  and 
Modeling),  research  report  prepared  by  Riehard  Riehle.  Unpublished,  2011. 

Nies,  M.  E.  2011.  Automated  Digital  Network  System  (ADNS).  Paper  presented  at  the 
Program  Manager,  Warfare  (PMW)  SPAWAR  130  and  160  Eleet  Stakeholders 
Conference,  June,  in  Norfolk,  Vbginia. 

Pressman,  Roger  S.  Software  Engineering:  A  Practitioner’s  Approach.  New  York, 
New  York:  Mo  Graw  -  Hill,  2010. 

Rognbe,  A.  B.  “An  Analysis  of  Return  on  Investment  of  the  Consolidated  Afloat 
Networks  and  Enterprise  Servioes  (CANES)  Program.”  Master's  thesis.  Naval 
Postgraduate  Sohool,  2010. 

Shah,  K.  2011.  ADNS  Quality  of  Service  (QoS).  Paper  presented  at  the  Program 
Manager,  Warfare  (PMW)  SPAWAR  130  and  160  Eleet  Stakeholders  Conference,  June, 
in  Norfolk,  Virginia. 

Sharp,  A.  and  P.  MoDermott.  Workflow  Modeling:  Tools  for  Process  Improvement  and 
Application  Development.  Boston:  Artech  House,  2009. 


101 


Stallings,  William.  Data  and  Computer  Communications.  Upper  Saddle  River,  New 
Jersey;  Prentice  Hall,  2011. 

Sullivan,  J.  A.  “Management  of  Autonomous  Systems  in  the  Navy''s  Automated  Digital 
Network  System  (ADNS).”  Master's  thesis.  Naval  Postgraduate  School,  1997. 

Swann,  K.  In  discussion  with  Bradley  May,  August  2,  201 1 . 

Turabian,  Kate  L.  The  Chicago  Manual  of  Style  A  Manual  for  Writers  of  Term  Papers, 
Theses,  and  Dissertations.  Published  online  at 
http://www.chicagomanualofstyle.org/tools_citationguide.html. 

United  States  Navy.  Consolidated  Afloat  Networks  and  Enterprise  Services  (CANES): 
Manpower,  Personnel,  and  Training  Implications,  research  report  prepared  by  H.  J.  Thie, 
M.  C.  Harrell,  A.  S.  McCarthy,  and  J.  Jenkins.  Santa  Monica,  California:  RAND 
Corporation,  2009. 

Yang,  C.  and  A.  V.  S.  Reddy.  “A  Taxonomy  for  Congestion  Control  Algorithms  in 
Packet  Switching  Networks.”  Institute  of  Electrical  and  Electronics  Engineers  (IEEE) 
Network  (July/ August  1995);  pages  34-45. 

5*  Annual  C4ISR  Government  and  Industry  Partnership  Conference,  2011 


102 


INITIAL  DISTRIBUTION  LIST 


1 .  Defense  Teehnieal  Information  Center 
Ft.  Belvoir,  Virginia 

2.  Dudley  Knox  Library 
Naval  Postgraduate  Sehool 
Monterey,  California 

3.  John  M.  Green,  MA,  MS,  MBA 
Naval  Postgraduate  Sehool 
Monterey,  California 

4.  Weilian  Su,  PhD. 

Naval  Postgraduate  Sehool 
Monterey,  California 

5 .  CAPT  Mark  Glover,  USN 
Commanding  Offieer 
SPAWAR  Systems  Center  Atlantic 
Charleston,  South  Carolina 

6.  Christopher  Miller 
Executive  Director 

SPAWAR  Systems  Center  Atlantic 
Charleston,  South  Carolina 

7.  Phillip  L.  Allen 

SPAWAR  Systems  Center  Atlantic 
Norfolk,  Virginia 

8.  David  P.  Gravseth 

SPAWAR  Systems  Center  Atlantic 
New  Orleans,  Louisiana 

9.  Michael  Brett  Huffman 
SPAWAR  Systems  Center  Atlantic 
Charleston,  South  Carolina 

10.  Richard  W.  Hughes 

SPAWAR  Systems  Center  Atlantic 
Norfolk,  Virginia 


103 


1 1 .  Bradley  J.  May 

SPAWAR  Systems  Center  Atlantic 
Charleston,  South  Carolina 

12.  Son  N.  Nguyen 

SPAWAR  Systems  Center  Atlantic 
Charleston,  South  Carolina 

13.  James  W.  Pinner 

SPAWAR  Systems  Center  Atlantic 
Charleston,  South  Carolina 

14.  Edgar  C.  Pontejos 

SPAWAR  Systems  Center  Atlantic 
Norfolk,  Virginia 

15.  Debra  R.  Reinertson 
SPAWAR  Systems  Center  Atlantic 
Charleston,  South  Carolina 

16.  Michael  J.  Roderick 
SPAWAR  Systems  Center  Atlantic 
Tiverton,  Rhode  Island 


104 


